73700+ entries in 0.043s
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?
diana_coman: asciilifeform, apparently
there is also various sizes bursts
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?
diana_coman: asciilifeform, any feedback re latest logs? anything else you'd want in
there?
diana_coman: asciilifeform,
that sounds very useful for eulora clients basically
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)
mod6: overall, sounds like you're making decent progress
tho
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
mod6: any chance
that
the data got consolidated into less packets?
diana_coman: I had
tcpdump sniffing at same
time and it reported same 19, not more
mod6: Ah. running
tcpdump at all
to log
the
traffic?
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: mod6, yes! onth a batch of 20 packets only rather
than 100 made it fully
diana_coman: but it does seem
to be just
too much for local setup/saturating basically
diana_coman: asciilifeform, ftr, just ran a batch 100 packets from UY
to UK and... 19 made it! oh boy
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
diana_coman: no, I am still fuzzing about; but will
try in a bit
diana_coman: logically speaking, one wouldn't expect
them
to be, no;
the foggiest part atm for me is
that interval from ~512 up
to ~1500
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
diana_coman: the pilot
test is UK -> UY (same as yesterday's)
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: ftr
tester sends as above payloads between 6 and 2048 rather
than 0 and 2048 because
the first 6 octets are
the header part (things like size sent and
time when sent)
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?
☟︎ diana_coman:
http://btcbase.org/log/2018-09-25#1854219 ->
tiny new pilot
test seems
to suggest it's not as bad as
that: all 100 packets of a batch (sent in burst mode, no delays) made it, with pseudo-randomly chosen sizes between 6 and 2048; predictably
though, order was messed up at
times
☝︎ a111: Logged on 2018-09-24 20:17 asciilifeform: well yes : conceivably 'frags in 2' worx ~100% of
time, but 'in 8' not etc
a111: Logged on 2018-09-24 19:43 mircea_popescu: diana_coman it occurs
to me
the work might also be misspecced. anyone have serious objections
to moving
to 1-2048 down from 1-65536 ?
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.
trinque: nope, I have not had
time
to implement
that
a111: Logged on 2018-09-25 01:06 asciilifeform: verisimilitude: make key, you will be able
to swap it later by asking politely of
trinque
verisimilitude: On
that
topic, I've been using GuixSD for a bit; what are you using, asciilifeform?
verisimilitude: I'm having issues on my
Thinkpad with it. I didn't have all of
the software installed here.
verisimilitude: If I don't get it before I run out of
time again, I'll just do it later.
trinque: verisimilitude: anyhow I wont mind swapping your key later if you want
to generate one in more sanitary conditions later, provided you sign for me
the new key with old.
trinque: the in-group cuts
the other direction here.
trinque: it's just
that in-group signaling about "tee hee lazy"
verisimilitude: Well, it probably wouldn't be
this long if I really had
to give it
that much
thought.
BingoBoingo: Think of it
this way, how many years have you kept your kidneys without losing
them?
verisimilitude: Once I get
this PGP nonsense sorted out, I'll
tell you a story.
verisimilitude: Freenode would really be fine with me, if it didn't block
Tor.
verisimilitude: I'd expect
those
this concerned would host
their own IRC.