I'm in the middle of a project that requires writing software that would send some packets over Ethernet every N milliseconds. The ethernet wire would go from a computer to a switch, and then to the rest of the network. There is no back-traffic, so packet only go out, nothing goes in. This "idealized" situation was created to measure jitter (time variability) of the packets. For example, even though we expect a packet to go out every 5ms, it will actually leave the computer every 5ms +- w where w is random uncertainty (i.e. jitter).
I would like to measure this jitter by hooking a scope to the internal wires of an Ethernet extension adapter, recording the waveform and looking at when bursts of data (packets) are transmitted. I'm making lots of naïve assumptions about Ethernet in general and CAT5 specifically, and so far I'm failing to see anything meaningful except of every possible flavor of noise. Therefore, I have questions.
First of all, can I even assume that no signals other than my packets are constantly being transferred back and forth between my laptop and the switch?
Secondly, does my probing scheme work at all? Can I simply connect two CAT5 wires with such adapter, break it open, strip insulation off wires and hook them to a scope? If yes, which wires should I be looking at?
Finally, can my 100MHz scope even handle the stuff that will be sent over my 100 Megabit connection? I only need to see whether a burst is present or not, so I thought it would be fine.
Are there any other suggestions on how I may do this alternatively?
Cheers! = )
Best Answer
No, you can not assume there will be no signal on the line just because you're not deliberately sending something at the network packet layer. There are things called link pulses, and there can be other negotiation going on between the switch and the PHY and possibly the MAC.
The best thing to do would be to let the MAC and PHY do their jobs. You can use a microcontroller with a MAC and PHY to blip a pin whenever one of your packets is received. You'd write a very bare "driver" that just waits for a packet at the MAC layer, blips a pin, then clears the packet. With such dedicated firmware, the jitter it adds should be quite small.
If you are willing to slow down your packet rate, you can do this even more easily. Most switches and other ethernet devices have send and/or receive LEDs. These are often blipped for a few 10s of ms when a packet is sent or received, which is why sending one every 5 ms won't work. If you send a packet every 100 ms, the LED should be off again when the next packet arrives. You can also wire up your own PHY and set it up to blip a pin a short time for each packet. That's basically what the chip in the switch is doing when it drives the LED.