* [Bloat] bufferbloat vs NetSpectre [not found] <CAA93jw6xj_-qUaeHBn-aoCKGAzG+KF0f3dCqcatYSAshUU6Mng@mail.gmail.com> @ 2018-07-31 2:59 ` Michael Richardson 0 siblings, 0 replies; only message in thread From: Michael Richardson @ 2018-07-31 2:59 UTC (permalink / raw) To: bloat [-- Attachment #1: Type: text/plain, Size: 1007 bytes --] I was reading through the NetSpectre paper at: http://misc0110.net/web/files/netspectre.pdf I haven't finished it all yet... key thing was on page 5, which starts with: if (x < bitstream_length) if(bitstream[x]) flag = true As I understand it, they are depending error packets that come back to measure cache fills from a background of packets that fail tests such as above. Two things occur to me: 1) in a really badly bufferbloated network, the super-long queues ought to completely screw things up for them. 2) fq_codel ought to something significant to the measurements. I don't know yet if it might them better or worse. But, it ought to do something. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 464 bytes --] ^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2018-07-31 2:59 UTC | newest] Thread overview: (only message) (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CAA93jw6xj_-qUaeHBn-aoCKGAzG+KF0f3dCqcatYSAshUU6Mng@mail.gmail.com> 2018-07-31 2:59 ` [Bloat] bufferbloat vs NetSpectre Michael Richardson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox