log☇︎
26600+ entries in 0.205s
mircea_popescu: i don't expect it's expensive, no. besides, very likely will be arbitrated rather than adjudicated
asciilifeform: mircea_popescu: unless i'm thick, this needs a specialist who's actually trustworthy, neh
mircea_popescu: i understood the complaint as "apparently someone somewhere is under the impression BingoBoingo can't get 3490874389 crates shipped because there's a law about local morons being limited to 2"
asciilifeform: all i got is that ??? email.
asciilifeform: mircea_popescu: the exact point of eggog is unclear to me, this is why i asked BingoBoingo to dig.
mircea_popescu: maybe i misread, but that wasn't the problem ?
mircea_popescu: "i get it, you have a law about your peons not being allowed to buy shit. good. so ?"
mircea_popescu: BingoBoingo you ever talked to the chinos ? i mean specifically the supermarket folks. they routinely blocade run, might be able to get you some shit ?
asciilifeform: i.e. i have nfi whether '4 in 5' or '100% after 3'
asciilifeform: BingoBoingo: do what remains to do to put a proper cross on the grave, and after that i'ma start taking cargo manifest calls.
asciilifeform: sorta why i posted a $5 cable the 1st time.
asciilifeform: mircea_popescu: i'm satisfied that BingoBoingo sniffed erry possible local arse for local source.
asciilifeform: the old newspapers is worth a shot. and if this fails, it'll have to run like antarctic station, i.e. supply rocket quarterly-semiquarterly, and priced in.
asciilifeform: mircea_popescu: can you think of less braindamaged ? ( say i had budgeted 9000 spares for april expedition. then we'd be sitting on 8994 lemon drives. )
a111: Logged on 2018-09-25 21:03 asciilifeform: i mean, wtf, enviro ?! what, this model of usb stick is banned in uy because does not include enuff % cow shit by mass ??
diana_coman: mircea_popescu, 1s delay seems to result at least on UK->UY direction on preserving even order at destination, at least at this hour; at any rate, I'll look at it tomorrow and unless I can spot some trouble, it should then be chugging along
asciilifeform: mircea_popescu: i think we have something like your earlier bank wire thing, going
diana_coman: my point above was that "derping for week+" + obscure "fault you have to fix" sounds precisely like "I keep asking for a bribe and I did not get any!!"
asciilifeform: 'tis a crying shame that mircea_popescu doesn't live in uy... i suspect there's a cunt somewhere who needs flaying.
asciilifeform: i mean, wtf, enviro ?! what, this model of usb stick is banned in uy because does not include enuff % cow shit by mass ?? ☟︎
BingoBoingo: Well, I'll have to read an go to the physical places tomorrow.
BingoBoingo: i.e. "environmentorast" agency
asciilifeform: how the fuck would i know !
asciilifeform: mircea_popescu: i'm beginning to suspect enemy action (i.e. some 'well-wisher' made a call to 'the right organs' in orcistan, or somesuch )
hanbot: <mircea_popescu> hanbot scheduled to patch ? << iirc this is second instance of query. i'll patch it this week, yes.
asciilifeform: ( this is, i shit ther not, how they actually work, approx )
mircea_popescu: i can't begin to guess why it'd go nowhere, i mean, a) insulting people by using their own words often works (on retards, why would it not work on people who say what they mean & mean what they say ?) and moreover b) summarization works on everything else, why'd trilema escape it and c) wtf is this strategic superiority jazz and who ever heard of the rhino-mud-birthday-gift issue. and so on
phf: actually, that is what's going on! but i'm not sure how it got that way, because i've both tested adacore's gnat ahead of time, and also had it building things. something must've gotten clobbered
ave1: phf: I suspect this modern systems has placed the C library and crt1.o etc in some wierd place
asciilifeform: for all i know, sanity requires typhus goin'round
mircea_popescu: it is the singular misfortune of the world that the sort of people who lived before computing lived before computing, and the sort living with computing are the sort we see around. i'd very much like these switched, give computers to that newman and give typhus to the current professor of logic.
mircea_popescu: dude manages, 50 or so pages in, to fully explain the fucking problem. "i gave up on this idiocy because upon first serious examination -- idiotic". i can see that.
mircea_popescu: meanwhile i simply can't not quote this :
diana_coman: to recap so I don't miss anything: no counter sent in header for packets; packets will have sizes between 6 (header length so minimum) and 2048; sender will have a 1second delay between each new package sent
mircea_popescu: i just meant, "nothing happens"
diana_coman: (it can be done though, if one really wants it, basically an Ada task to be repeated hourly, but I don't see the benefit to that)
mircea_popescu: yeah, i don't think we're trying to study bursts or saturation here. rather a study of the route under best conditions so to speak.
diana_coman: http://btcbase.org/log/2018-09-25#1854302 -> I took that to mean he wants to select only those of a given size, hence ..yes, easy ☝︎
a111: Logged on 2018-09-25 15:37 mircea_popescu: http://btcbase.org/log/2018-09-25#1854224 << i don't think it is.
a111: Logged on 2018-09-25 15:58 mircea_popescu: http://btcbase.org/log/2018-09-25#1854282 << i don't get it, 50 packets / hour is less than 1 per minute. this can't saturate anything. are you doing the burst in the sense of just dumping all the packets on the interface in 2 s and waiting the 3598 other s idle ?
phf: (the previous error i mentioned in logs was probably using same compiler before it was installed into its destination, because it was being invoked with explicit -B flags (-B flag points to compiler bits explicitly). this new failing bootstrapped compiler would work if provided explicit -B which makes me guess that some phase that was supposed to get compiler into knowing where its bits are failed.)
phf: well, i have some idea what's going on, the binutils build is attempting to use bootstrapped gcc, which in turn can't find its own link objects, one sec on log
phf: mircea_popescu, ave1 http://p.bvulpes.com/pastes/QtjVR/?raw=true this was the log from the last invocation, but i'm not sure if it's representative of an issue. this was downstream from a handful of hacks and manual invocations
asciilifeform: makers of physical objects, i can reluctantly forgive for failing to produce shelfifier. but those of ideal objects -- for them there can be no forgiveness
asciilifeform: mircea_popescu: reminds of ancient convo b/w asciilifeform and pet : 'p : 'i want a shelfifier' a: 'you mean, a shelf' p : 'no, shelfifier' a: '...' p: 'device that produces shelf where and when needed, then removes' '
mircea_popescu: "but mp... eventually... you'll have to do SOMETHING." "yes, and even without that maybe eventually i will do something. this gives no one license to pretend the inadequacy of ontos is now gnosis' problem."
mircea_popescu: "i want a girl" "how about mary ?" process. if i wanted fucking mary, i'd have fucking said i want mary.
asciilifeform: no i get it
mircea_popescu: i'm currently connected through the internet through sheer force of will, and there's a tcp thing trying to rape this.
mircea_popescu: i'm not.
asciilifeform: wouldn't go this far; dunno about mircea_popescu , but i'm presently connected to fleanode, trb, etc via tcp
mircea_popescu: all through the attempt the question would be "why did you expect martian poop is culinary item" and i'd have no answer and it'd drive me mad.
mircea_popescu: of martian poop. i don't even live on mars.
mircea_popescu: and i didn't write the lifestory of rms, and so on. not everyone is c s lewis.
mircea_popescu: i'm not writing the "lifestory of linus", either. for the same exact reason -- who the fuck is he ?
mircea_popescu: im not fucking writing that. i don't like tcp enough.
mircea_popescu: asciilifeform i've been on and off looking through for the past coupla weeks.
phf: ave1: just fyi i punted on trying to get it operational on a "recent" linux. i hacked around the isystem issue, and ran into something else entirely downstream. also it is a "recent" linux issue, because it builds fine on as-heathen-as-it-gets centos 6.7 (2016 or so)
a111: Logged on 2018-09-25 15:23 asciilifeform: ( i.e. without the plaintext control messages, where any thirdparty derp can close your connection, infer contents via burst lengths, etc )
a111: Logged on 2018-09-25 15:05 diana_coman: aha; meanwhile playing here with the dubious UY->UK direction and I'd say it's pretty clear that bursts of more than 50 packets or so increase packet loss visibly; I suppose this makes for a nice thing to look at specifically once I get one week of data or so
mircea_popescu: http://btcbase.org/log/2018-09-25#1854282 << i don't get it, 50 packets / hour is less than 1 per minute. this can't saturate anything. are you doing the burst in the sense of just dumping all the packets on the interface in 2 s and waiting the 3598 other s idle ? ☝︎☟︎
a111: Logged on 2018-09-25 14:57 asciilifeform: diana_coman: i'd like to see a test where there is only 1 size, across various sizes, if possible
a111: Logged on 2018-09-25 12:30 diana_coman: uhm, correction re above since I messed up the pilot test earlier (sender sent 100 as shown, but receiver waited for only 50 and then turned off so not much use); updated pilot test with receiver properly looping forever and sender sending 100 packets: 81 of those made it; sender log: http://p.bvulpes.com/pastes/zs4p5/?raw=true ; receiver log: http://p.bvulpes.com/pastes/4qiPb/?raw=true
a111: Logged on 2018-09-25 11:13 diana_coman: following from the above: currently order and order-mismatches *can* be calculated at data analysis time based on the 2 logs; alternatively, I could add another 2 octets to the tester's own header to store an order number so receiver can also report directly any order-mismatch - not sure if that's worth it though, any thoughts on it?
mircea_popescu: http://btcbase.org/log/2018-09-25#1854224 << i don't think it is. ☝︎☟︎
asciilifeform: ( i.e. without the plaintext control messages, where any thirdparty derp can close your connection, infer contents via burst lengths, etc ) ☟︎
asciilifeform: i picture the end product as something like tcp but without the retardations.
asciilifeform: diana_coman: i have a suspicion that saturation bursts trigger anti-ddos hackolade in some places
asciilifeform: i suspect this'll be very frag-sensitive
diana_coman: aha; meanwhile playing here with the dubious UY->UK direction and I'd say it's pretty clear that bursts of more than 50 packets or so increase packet loss visibly; I suppose this makes for a nice thing to look at specifically once I get one week of data or so ☟︎
diana_coman: isn't this something more for next step at data analysis? (i.e. minus the two logs and highlight missing stuff)
diana_coman: asciilifeform, well, how can it know? i.e. they might come...later, no?
asciilifeform: diana_coman: i'd like to see a test where there is only 1 size, across various sizes, if possible ☟︎
asciilifeform: ( naturally this is only applicable to synchronous, i.e. A->B, B->A, A->B, .... , comms )
diana_coman: mod6, certainly; I'll wait pretty much for any feedback on it all and otherwise it's quite ready to run for a week or more (receiver always on, sender as some hourly cron taks)
asciilifeform: btw i'd like to share an old asciilifeform algo; not sure if directly applicable to diana_coman's proggy, but may come in handy: for synchronous packetron. to determine when to resend a packet, you wait time T; T is initially a pessimistic value, e.g. 800 msec; but once you start getting responses, you set it at all times to the ~minimal~ response delay observed thus far. and if reply wait exceeds T, you resend & restart the clock.
diana_coman: I wanted to run this because it mimics much closer eulora client<->server communications but otherwise might set up different end nodes
diana_coman: tbh if anything I start suspecting at most the router
diana_coman: I had tcpdump sniffing at same time and it reported same 19, not more
diana_coman: mod6, as far as I can tell they got lost in transit but I don't know *how close* to the machine itself (this UK machine is behind a router, I've set up port forwarding for it); basically atm the UK->UY vs UY->UK is pretty much client->server vs server-> client communication
mod6: the missing ones didn't hit the interface either? i.e. they were lost in transit, not once they hit your interface?
diana_coman: will do; I can think of a few other routes as well but possibly first have it run on one route for a while and then expand
asciilifeform: aite, i'ma not distract then
diana_coman: no, I am still fuzzing about; but will try in a bit
asciilifeform: i strongly suspect that heavy (i.e. always-fragged) packets are not ultimately a bw win
diana_coman: I can certainly run such a test too if we want to check that specific situation; now that I got ~everything in place, knobs can be easily turned for sure
asciilifeform: diana_coman: i suspect that the % of surviving fragged packets will drop as you saturate the link ( with e.g. GB thrown at line speed )
diana_coman: uhm, correction re above since I messed up the pilot test earlier (sender sent 100 as shown, but receiver waited for only 50 and then turned off so not much use); updated pilot test with receiver properly looping forever and sender sending 100 packets: 81 of those made it; sender log: http://p.bvulpes.com/pastes/zs4p5/?raw=true ; receiver log: http://p.bvulpes.com/pastes/4qiPb/?raw=true ☟︎
diana_coman: the last column in the receiver log is now a count of payload octets that are different from what is expected - if any such octets are observed, the receiver will log now their actual position + value in a different log file; so far I haven't seen any error of this type
diana_coman: following from the above: currently order and order-mismatches *can* be calculated at data analysis time based on the 2 logs; alternatively, I could add another 2 octets to the tester's own header to store an order number so receiver can also report directly any order-mismatch - not sure if that's worth it though, any thoughts on it? ☟︎
a111: Logged on 2018-09-25 09:06 diana_coman: http://btcbase.org/log/2018-09-24#1853827 -> sounds at least like something worth getting some data on, yes; I wouldn't even be surprised if ~any frag results in mostly lost packets
diana_coman: http://btcbase.org/log/2018-09-24#1853827 -> sounds at least like something worth getting some data on, yes; I wouldn't even be surprised if ~any frag results in mostly lost packets ☝︎☟︎
mircea_popescu: and no, most boxes speak 1mn:1 more to the net than to me. and if this weren't the case, i wouldn't keep 'em.
mircea_popescu: i... don't do that.
asciilifeform: ( lulzily i got sensors, uarts, etc on 10m nics all the while... on modern day switchen this worx without interfering )
asciilifeform: of course also got boxen pumping MB+/s to net, day an' night, and i ~like~ that they dun saturate the lan while so doing
a111: Logged on 2018-09-25 00:10 mircea_popescu: but i suppose if you're running a camwhore site or something.
asciilifeform: narrowly missed answring http://btcbase.org/log/2018-09-25#1853975 : i move 100GB+ barrels of vm liquishit over gb nics ~weekly, on lan, would suck on 100m. ☝︎
trinque: nope, I have not had time to implement that
mircea_popescu: http://btcbase.org/log/2018-09-25#1854166 << i live under the impression this is automatic, just reg new key and v with old key ☝︎