tmsr - Search: diana

3600+ entries in 0.033s

asciilifeform: diana_coman & mod6 will get brand new disks when they signal readiness for downtime

asciilifeform: diana_coman, mod6 , lobbes : if yer feeling brave, can also keep old drive on usb2 jack, as auxiliary storage, see just how long they live...

asciilifeform: diana_coman, mod6 , lobbes , also give signal re whether you want the newer iptables-enabled kernel to go on your boot sd , when we take the boxen down ( iirc we already did mod6's ) ☟︎

asciilifeform: diana_coman, mod6 , lobbes , let BingoBoingo & asciilifeform know when is good day to take down yer units and copy contents to new drives. ☟︎

a111: Logged on 2018-10-01 14:25 diana_coman: I think that's precisely what the chairs need to figure out: "what might fit under this " and be useful, ofc

a111: Logged on 2018-10-01 14:23 asciilifeform: diana_coman: that's uncharted territory..

a111: Logged on 2018-10-01 14:22 diana_coman: asciilifeform, my understanding is that tbf's scope is not limited to trb, nor focused specifically mainly on trb

mod6: Thanks diana_coman.

asciilifeform: diana_coman: i'm sold.

a111: Logged on 2018-10-01 09:04 diana_coman: phf, please add the fix patch to eucrypt http://ossasepia.com/reference-code-shelf/#selection-391.0-399.38

asciilifeform: diana_coman: i dun particularly care who in l1 does it, for so long as it keeps being done.

asciilifeform: diana_coman: that's uncharted territory.. ☟︎

asciilifeform: diana_coman: right, pretty much all of the early vtronics work happened on tbf ml

ave1: diana_coman, thanks! yes I see and I did forget

a111: Logged on 2018-10-01 03:22 mircea_popescu: diana_coman is that getting a patch or what ?

mircea_popescu: diana_coman is that getting a patch or what ? ☟︎

a111: Logged on 2018-09-30 15:19 Mocky: asciilifeform, diana_coman: my phone's not paid off so can't unlock. maybe those hundies that could pay it off will find a better use in the short term, so that's why cheap second phone. and yeah, roaming turned off.

asciilifeform: diana_coman: not particularly urgent experiment, i dun expect we'll do anyffing constructive with the output until after regrinds etc

asciilifeform: diana_coman: there's at least 2 in there

Mocky: asciilifeform, diana_coman: my phone's not paid off so can't unlock. maybe those hundies that could pay it off will find a better use in the short term, so that's why cheap second phone. and yeah, roaming turned off. ☟︎

asciilifeform: diana_coman: if you find it in the l0gz, plox to link

asciilifeform: diana_coman: there was a site (nao dead! incidentally.) with didactic/trivial pieces

asciilifeform: diana_coman: interestingly, just about my entire collection of vintage ada, with the exception of that little serpent thing, qualifies for this museum.

asciilifeform: diana_coman: thing is eminently fit for 'museum of sad ada'

asciilifeform: diana_coman : http://ossasepia.com/2018/09/27/tester-for-udp-communications/comment-page-1/#comment-4249

asciilifeform: ohai diana_coman et al

asciilifeform: ( or see diana_coman's rsa walkthrough, http://ossasepia.com/2018/02/15/eucrypt-chapter-10-oaep-with-keccak-a-la-tmsr/ )

asciilifeform: diana_coman: http://btcbase.org/log/2018-09-28#1855195 << output ☝︎

asciilifeform: diana_coman: 10ms

asciilifeform: diana_coman: all of my testfires thus far ended up 'no loss, no reorder, as if on lan'

a111: Logged on 2018-09-28 06:24 diana_coman: asciilifeform's published test data seems to match what I got on my initial tests with 1 second delay; my current plan is to collect first at least 1 week worth of data and then to repeat the experiment with a. smaller delays b. several senders perhaps

asciilifeform: http://btcbase.org/log/2018-09-28#1855291 << lemme know if you'd like sumthing in particular tested with my path, diana_coman ☝︎

a111: Logged on 2018-09-28 00:39 asciilifeform: mircea_popescu, diana_coman : http://nosuchlabs.com/pub/udpism/usa_sender_udp_log.txt http://nosuchlabs.com/pub/udpism/uy_receiver_udp_log.txt << 1 full volley

a111: Logged on 2018-09-28 00:20 mod6: nice work diana_coman

a111: Logged on 2018-09-27 09:34 diana_coman: http://barksinthewind.com/2018/vtools-keccak-regrind/ -> gotta ask here, phf, am I missing something or what Wednesday was that there in the first line meant to be?

mircea_popescu: and diana_coman or hanbot or who will you pick have little problem in turning over next-day keccak patches on trees, as recently put on display. i don't think they're either smarter or blesseder than you, they just have the toolset ready.

asciilifeform: btw mircea_popescu & diana_coman , not only 0 packet losses, but 0 reorders.

asciilifeform: mircea_popescu: just nao -- muscle-powered v a la diana_coman . this weekend would like to reword v.py to run on phf's components.

asciilifeform: mircea_popescu, diana_coman : http://nosuchlabs.com/pub/udpism/usa_sender_udp_log.txt http://nosuchlabs.com/pub/udpism/uy_receiver_udp_log.txt << 1 full volley ☟︎

mod6: nice work diana_coman ☟︎

asciilifeform: diana_coman's test jig ( i did not modify it except for the dest ip ) currently fires 1 / sec.

asciilifeform: diana_coman: built & emplaced your sender-receiver, it is running nao, asciilifeformistan <--> BingoBoingostan

asciilifeform: diana_coman: i'ma test & mirror that one when i get a chance

asciilifeform: ( asciilifeform plowed through the phf-vtronics thread when came back from voyage, and then second time when diana_coman requested keccak regrind, and both times failed to converge to correct answ re 'is there complete keccak vtron' )

asciilifeform: http://btcbase.org/log/2018-09-27#1855075 << yea if i'd smoke-tested it earlier, would have found. on top of this, naively assumed that diana_coman has a working and complete keccaktronic v , given as she's moved smg to newform ☝︎

a111: Logged on 2018-09-27 12:47 diana_coman: since I need to get the work done on this, I reground the UDP lib and I'll proceed from there; asciilifeform, phf and anyone else interested, keccak-patches are on my Code Shelf as usual: http://ossasepia.com/reference-code-shelf/#selection-477.0-477.19

a111: Logged on 2018-09-27 13:50 diana_coman: asciilifeform, np; re vtron yes, currently it is only vdiff and vpatch functionality; I use old v to see the flow (since it checks the seals but doesn't care about the hashes until press time) and then the vpatch to actually press; looking forward to esthlos' vtron

asciilifeform: apparently diana_coman has been hand-cranking it, sorta like asciilifeform's 1st yr of trb pre-vtron

asciilifeform: and yes it is the picture i got from log. the gap in my head is where diana_coman switched to the new format; i then assumed there is a 100%-complete new vtron, and that 'hmm simply missed this, is in log somewhere' , turns out nope, notyet

asciilifeform: diana_coman: is there a version of mod6's vtron that uses the new vdiff / vpatch ? or what do you use in erryday work ?

asciilifeform: danke schon, diana_coman . feel free to rename the filez.

asciilifeform: diana_coman: http://www.loper-os.org/?p=2557 updated, with mirror and seals (yours, mine)

asciilifeform: and loox like diana_coman even added comments.

asciilifeform: ty diana_coman .

asciilifeform: aaand it loox like diana_coman already did my chore for me... i'ma do the elementary test on it nao, and sign/mirror.

asciilifeform: diana_coman: do you normally use this with a hand-patched mod6 vtron ? or how ?

a111: Logged on 2018-09-27 09:41 mircea_popescu: did you follow diana_coman 's http://barksinthewind.com/2018/vtools-keccak-regrind/#comment-27 ?

a111: Logged on 2018-09-27 09:31 diana_coman: http://btcbase.org/log/2018-09-27#1854882 -> got your .tar.gz but I could not find in it the .wot and .seals? at any rate, if I copied over the .wot and .seals dirs, it pressed perfectly fine with v here (9999 K version); ftr I ran also precisely the v.pl you have in there and it also worked!

asciilifeform: http://btcbase.org/log/2018-09-27#1854926 << ~this~ is pretty strange; diana_coman wouldja mind sharing your working set there ? ☝︎

mircea_popescu: did you follow diana_coman 's http://barksinthewind.com/2018/vtools-keccak-regrind/#comment-27 ? ☟︎

asciilifeform: mircea_popescu & diana_coman specifically asked asciilifeform to rebake udp proggy in keccak.

a111: Logged on 2018-09-26 18:46 diana_coman: asciilifeform, udp tester seems to be nicely running uk->uy and uy->uk so my next step on this will be to publish all the relevant code; since this is effectively on top of udplib, I'd patch it on your tree; mind moving it though to keccak?

asciilifeform: mod6: i sat down and resolved to give diana_coman the promised item, but presently loox like won't happen tonight

asciilifeform: diana_coman, mircea_popescu , et al -- plox to reveal what you pressed this tree with , thx

a111: Logged on 2018-09-19 17:44 asciilifeform: mircea_popescu: right now asciilifeform , diana_coman , errybody, has buncha vdiff laying around, not only on www but on own disks, and serious problem if gotta stab at it by hand erry time to see which it is.

asciilifeform: would rather switch wholesale to phf's, since it apparently performs to satisfaction of diana_coman

asciilifeform: mod6: i've been using my orig vtron all this time. but recently diana_coman & mircea_popescu prodded, 'what's yer excuse for not moved to modern keccak-v' and i had no good counter, it's really time, so nao gotta actually uncrate phf's and make it go

mod6: <+diana_coman> asciilifeform, hm? I can't quite parse that q; if it helps: I'm using phf's vtools, yes << I'm a bit confused too. I'm still using my vtron.

asciilifeform: diana_coman: ty, was all i needed

asciilifeform: diana_coman: i.e. http://barksinthewind.com/2018/vtools-keccak-regrind/ ?

asciilifeform: diana_coman, mod6 , phf , et al : is the 'canonical' (i.e. most recent usable) oldv-tree of newstyle-v the one on phf's www ?

asciilifeform: diana_coman: if you'd rather proceed immediately, and generate a newstyle tree, i'ma read it and sign also.

asciilifeform: diana_coman: i'ma bake a new-style set and post closer to nightfall, currently boiling in cauldron of liquishit

asciilifeform: diana_coman: what's the fastest way to do this ? ( i.e. do you recall whether phf published his converter ? or do i gotta crank it manually )

mod6: diana_coman has a point, aren't we supposed to grease the wheels in such a palce?

asciilifeform: diana_coman: normal people make bakshish request with a 'pay here'

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

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 13:37 asciilifeform: diana_coman: lemme know btw if you'd like to send me the sender and do a packet survival run to/from asciilifeformistan

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?

asciilifeform: diana_coman: i have a suspicion that saturation bursts trigger anti-ddos hackolade in some places

asciilifeform: diana_coman: afaik, the remaining fundamental variants are 1) single-sized volleys, for various sizes 2) this, and the earlier variant, at max possible saturation

asciilifeform: diana_coman: can you set it display the ones that ~didn't~ make it

asciilifeform: diana_coman: i'd like to see a test where there is only 1 size, across various sizes, if possible ☟︎

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.

asciilifeform: diana_coman: lemme know btw if you'd like to send me the sender and do a packet survival run to/from asciilifeformistan ☟︎

asciilifeform: diana_coman: have you tried in reverse path ?

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 )

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

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 ?

asciilifeform: yea as i understand diana_coman already has the knobs, can turn'em when she wakes up

asciilifeform: btw , esp for diana_coman , e.g. 1000 byte payload will be a 1028 byte total mass. (header)

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 ? ☟︎

a111: Logged on 2018-09-24 13:50 diana_coman: hm, a first tiny pilot test of the UDP send/receive looks quite dire (4 in 20 made it, when sent in batches of 4, random lengths); however, I don't know if it's not just overflowing the out buffer to start with (since default value in /proc/sys/net/core/wmem_default is 212992 so real would be half that iirc)

a111: Logged on 2018-09-24 15:11 asciilifeform: diana_coman: traceroute --mtu destinationip will show the mtu of the 1st 'fraggable' node in the path

asciilifeform: diana_coman: traceroute --mtu destinationip will show the mtu of the 1st 'fraggable' node in the path ☟︎

asciilifeform: diana_coman: https://archive.is/k6Wxb << udpism likbez ( may or may not contain anyffing new to you, but posting for the l0gz/n00bz )