[HN Gopher] From Oscilloscope to Wireshark: A UDP Story
___________________________________________________________________
From Oscilloscope to Wireshark: A UDP Story
Author : mkeeter
Score : 156 points
Date : 2022-08-11 16:21 UTC (6 hours ago)
(HTM) web link (www.mattkeeter.com)
(TXT) w3m dump (www.mattkeeter.com)
| jeffrallen wrote:
| Being able to recruit people like Matt is why Oxide will win.
|
| Go team Oxide, we're rooting for you!
| ru552 wrote:
| Thank you. This was a great read.
| phibz wrote:
| It's nice to see rust in an article not about rust.
| sitzkrieg wrote:
| nice writeup! and i thought RMII was hard to deal with
| thatcherc wrote:
| The scope's sample rate really jumped out to me:
|
| > I configured the oscilloscope to collect 100M samples at 1 TSPS
| (tera-sample per second, 10^12) ...
|
| Wow! Sampling at 1000 GHz? I wouldn't have thought that was
| possible! Does anyone know how the scope can even do that?
| extrapickles wrote:
| In general the slow part is getting the data out of the ADCs,
| so by interleaving multiple you can increase the speed. To
| reduce costs, if you have a repetitive signal, you can trigger
| the ADCs at different points in the waveform to build up a
| better idea of what is going on.
|
| For scopes that can do these high sample rates they frequently
| use two lasers and have the scope capture the beat between them
| as a demo of how fast they are.
| tverbeure wrote:
| The Signal Path has a teardown of the Keysight UXR
| oscilloscope, which has a BW of 110GHz and samples 4 channels
| at 256Gbps/channel, with 10bit resolution:
| https://www.youtube.com/watch?v=DXYje2B04xE.
| mkeeter wrote:
| Good question - it's _actually_ sampling at 50 GS /s (the
| scope's maximum sample rate), then upsampling by interpolation.
|
| The higher sample rate is useful, because it effectively gives
| higher precision when finding the zero crossings; however, you
| could reduce the .wfm size by sampling at 50 GS/s on the scope
| then upsampling on the computer.
| jeffwheeler wrote:
| You can use the 8b/10b decoding directly on your Tek MSO
| scope to do most of the preprocessing here. You can even
| trigger on errors. It would be easier than analyzing the
| analog stream directly.
| exmadscientist wrote:
| > upsampling on the computer
|
| That would be better. Upsampling on a scope is _dangerous_ ,
| it's just too easy to fool yourself about what you're really
| seeing. Much better to use a slightly more clever algorithm
| on the PC than just "nearest crossing".
| matthberg wrote:
| Huh, analogous to RAW photography and postprocessing rather
| than on-camera jpg creation, I guess.
| exmadscientist wrote:
| Also just that the interpolation and curve fitting
| algorithms on scopes are often utter garbage.
|
| We tested the 5 Series predecessor to your 6 Series and I
| was amazed to see 10 or so volts on a 3.3V logic
| signal... until I remembered to check the interpolation
| setting. There was, in fact, no measurement above 3.3V
| (ok, within the usual tolerances) but the dumb shit
| machine had made things up and displayed them as if they
| were real. Even though they would have meant there was a
| serious hardware fault (not impossible, it was a new
| design going through bringup and there were in fact
| higher voltages on the board!), nope, it was the fault
| finding tool that was faulty.
|
| I've had zero interest in the 5 Series since that demo
| week. Terrifying machine. (And it was supposed to have
| been "debugged" by that time.)
| nazgulsenpai wrote:
| There are so many levels of mind-boggling engineering between the
| analog electrical signal going into the PSU to the packets
| travelling across the wire/air that I take for granted. This post
| really helps me visualize how complex even the simplest of
| network processing truly is.
|
| Thank you!
| TheDesolate0 wrote:
| Animats wrote:
| If you have to debug at that level, and you're not designing
| hardware, things are really bad.
|
| Some years back, Wes Irish at Xerox PARC tracked down one of the
| great mysteries of early coax Ethernet - why was throughput so
| much lower than theory predicted? For this, he got both ends of a
| building-length coax with many machines on it connected to one
| office, so he could plug both ends into a storage scope. If the
| waveforms disagreed, somebody was transmitting when they
| shouldn't. Storage scopes with large storage were rare then. It
| was an expensive LeCroy unit.
|
| After the end of each Ethernet packet on coax, there is a brief
| "quiet time", and then the next packet can be sent, beginning
| with a sync pattern. The hardware detects if what it is sending
| does not match what it is receiving, which indicates a collision.
| Both senders stop, wait a random time so they don't collide
| again, and retry. This is how "carrier sense multiple access -
| collision detection", or CSMA-CD, works at the hardware level.
|
| This setup revealed that something on the cable was transmitting
| a single spike after the end of each packet, during the "quiet
| time". That reset the "quiet time" timer in the network
| interface, which inhibited the transition to "look for sync"
| mode. So the next packet would be ignored. The quiet time timer
| was at a very low level - software did not see this event.
|
| What came out of looking at the waveforms was the surprising
| result that the spike during the quiet time was not coming from
| either the data source or the destination, but from something
| elsewhere on the cable. The spike was not synchronized to the
| packet just sent. With the waveforms for both ends of the cable
| visible, speed of light lag revealed both that this was happening
| and where it was coming from, as distance along the cable.
|
| It turned out that several brands of network interface used a
| part which contained the quiet time timer, the sync recognizer,
| and the transmitter power controller. When the timer ran out, the
| device did a state machine transition, and during that
| transition, for a nanosecond or so, the transmitter turned on. It
| wasn't supposed to do that. This generated a spike on the cable,
| resetting every quiet time timer and causing the next packet to
| be silently ignored by all stations.
|
| The network interface didn't need to be active to do this. Being
| powered on was sufficient. One device with that part could halve
| the data rate on a coax Ethernet. Thousands of network interfaces
| had to be scrapped to fix this.
| bcantrill wrote:
| Wow -- that's an incredible story! (Was this ever formally
| written up somewhere? Definitely feels like it deserves it!) I
| am especially curious about using the lag; it sounds like both
| ends of the cable were plugged into the same scope? That must
| have felt exhilarating to finally find!
|
| Also, some things never change: the scope that Matt was using
| for this is (still) an expensive LeCroy unit...
| Animats wrote:
| Yes, both ends of the cable were plugged into the same scope.
| I got to see the scope with the waveform at PARC, because I
| was asked to take a look at the result.
|
| There was quiet faxing of waveform pictures to certain IC and
| board manufacturers. Not much publicity. This was in the
| 1980s. Ethernet was a niche product.
| [deleted]
| mpalme wrote:
| Posts like these are the reason I come here. Kudos!
| antegamisou wrote:
| Same, but they have become extremely rare. Most submissions on
| front page have LinkedIn grifter vibes nowadays.
| ChrisMarshallNY wrote:
| Excellent post. As an EE that turned soft, articles like this
| make me smile.
___________________________________________________________________
(page generated 2022-08-11 23:00 UTC)