Qualifying (quantifying?) precision network time synchronization

Hi,

I need to "quantify" the performance of three different network synchronization algorithms I've implemented:

- PTP (& -ish)

- PTP (& -ish) without special MAC

- a proprietary implementation

I figure I can use a degenerate network configuration to give me absolute "best case" values (two devices w/ XOVER cable and careful control over the activities in each node).

I can also come up with some numbers for "typical" performance as well as quantifying that traffic.

The problem is figuring out what "worst case" values I'll see in a deployed configuration (i.e., where I have little or no control over the other network devices). To be more specific, how to inject traffic onto the wire with deliberate intent to degrade my control (short of the pedantic case of effectively "shorting" cables for indefinite periods of time)

Do they make boxes that deliberately do this (i.e., precise control over the sizes and content of packets as well as precisely *WHEN* they are placed on the wire)? Some pointers to products -- or suitable search terms -- would be appreciated!

Thanks!

--don

Reply to
D Yuniskis
Loading thread data ...

Can't answer the *WHEN* question, but I've seen a Candela box used to simulate DOS attacks.

formatting link

Looks highly uncheap to me.

Another possibility is hacking the open source packETH generator to have the features you need:

formatting link

OTOH very cheap.

Reply to
Jim Stewart

This is proabably obvious, but you can quantify what's happening with a network monitor tool like wireshark on an added pc, if you wire the nodes via a hub (not a switch). Wireshark has timestamps for every packet traced and quite fine resolution, iirc. You could also arrange a fourth windows or linux box node to inject traffic, such as file transfers, ping series etc, to disrupt the traffic between the nodes of interest.

That's just a trivial solution. Anything else might need specialist network tools, or custom software on another node...

Regards,

Chris

Reply to
ChrisQ

[ ... ]

There are various "network simulators" out there that will probably do what you're after. I seem to recall one (I think it was FreeBSD based) that could be used to randomly delay, reorder, and drop packets based on lots of configuration options.

Putting a box with two network interfaces running something like that, between your machines of interest should get pretty close to what you're after.

Unfortunately, it's been a long time since I did the research on this subject (over 10 years), so what's out there now isn't very congruent to what I was finding. Many current ones seem targeted at CCNA tests, sigh.

--
Steve Watt KD6GGD  PP-ASEL-IA          ICBM: 121W 56' 57.5" / 37N 20' 15.3"
 Internet: steve @ Watt.COM                      Whois: SW32-ARIN
 Click to see the full signature
Reply to
Steve Watt

'arbitrary signal generator' is what we used in the past. perhaps now available in a 'digital' form or configurable for same.

good luck

Reply to
1 Lucky Texan

I think both give more control over *content* and "quantity" than *timing* -- especially the latter (since it runs on generic hardware).

I wonder if I might be better off just wiring a PHY to a state-machine and triggering it from some sort of programmable waveform generator (or, a "bigger" state machine).

Note that I don't need this "other" box to participate in the PTP protocol -- my two boxes can do all of that work "with each other". So, all I really need to be able to do is force directed traffic onto the network at "undesirable times" to force the switch(es) to queue "desirable" packets to effectively increase jitter in the PTP traffic. And/or "force" PTP packets to be dropped.

Reply to
D Yuniskis

I assume they are running on generic hardware? (I will google) As such, they probably don't have the precise level of temporal control that would be necessary (i.e., on the order of network bit times). And, if I had to modify one of these, I get myself back into the chicken-egg problem (i.e., how do I quantify the test box's behavior)

Let me see what google says for "network simulators"...

Reply to
D Yuniskis

I think it would have to be considerably more complex than just that. :< But, I could probably use something like that to *trigger* a piece of dedicated hardware that talks to the wire...

Reply to
D Yuniskis

I'm looking at timing on the order of bit times (i.e., better than a microsecond). I can measure the "synchronization error" by simply telling the two boxes to do something periodically and *measure* the time/phase difference between those two systems' actions.

I suspect that ("tools") will be the case. But, I might be able to fabricate something that is "good enough" instead of having to purchase a "general purpose" tool that has these abilities

Reply to
D Yuniskis

Haven't used anything but the default, which timestamps down to the nearest microsecond, but the help file says settings down to nanoseconds.

It's a free download, so might be worth having a look...

Regards,

Chris

Reply to
ChrisQ

D Yuniskis schrieb:

It is not what you asked for, but maybe a software simulation is worth considering:

formatting link

Reply to
Sebastian Doht

Many labs have an HP 16500 series logic analyzer. If you can scare up a 16520A pattern generator card, you might be good to go.

Reply to
Jim Stewart

I bought a system from Endace.

Reply to
Spehro Pefhany

Why don't you just wire an (eg.) Natsemi IEEE-1588 capable PHY to a FPGA development board?

Reply to
Spehro Pefhany

If you need just 1 us accuracy, take a look e.g. how for instance EtherCAT synchronization is implemented.

Anyway, after initial synchronization and using reasonable spectrally clean crystal oscillators, you just have to compensate for temperature drift in the nodes and in the very long term compensate for crystal aging.

Thus, you could use integration times measured in hours to maintain lock between the oscillators in different nodes, thus effectively averaging out any propagation time jitter.

Reply to
upsidedown

The problem with this approach is it requires me to *know* how the "other network devices" behave -- in order to model them for the simulation. :<

But thanks for the link! I will explore this and see if it is worth adding to my toolkit!

--don

Reply to
D Yuniskis

Digging through their web site, it seems like their devices are only used for *measurement*. I.e., I see nothing that lets me inject traffic (or disturbances) precisely...

I can *measure* how well devices synchronize quite easily. The problem is one of stress testing the implementation to verify that it behaves as designed in adverse conditions.

Reply to
D Yuniskis

Yes, my concern is that it knows nothing about the hardware that it is running on. E.g., what sort of delays exist in the network interface itself -- and, how *elastic* those might be! So, while it may be able to say "I saw this at t=X.XXXXXXXX", there is no guarantee that it wasn't actually on the wire at t=X.YYYYYYY. :<

Yes. I'll see if I can sort out what their real claims are vs. what is "implied".

Thx!

--don

Reply to
D Yuniskis

It does know what network card it's connected to, as it provides a list to select from, but whether it's smart enough to compensate for system delays, I don't know. However, if it's running on a third machine from the two under test, it should time stamp the packets from each machine with more or less the same time offsets due to packet processing. This means that ideally, you want no other apps running on the ws machine, or, ie: minimum system load to get the lowest jitter on timestamp results. Have run it on P3/500 class machines, but suspect that it really needs p4 1.5Ghz or xeon 2.8 class machine to get the best result for the sort of problem you are trying to crack.

I used tcpdump on unix for years and still do from time to time, but it's command line only. ws has a very powerfull front end gui and has some serious commercial backing as well, even though it's still a free download.

You know the saying: use all available tools :-)...

Regards,

Chris

Reply to
ChrisQ

It does know what network card it's connected to, as it provides a list to select from, but whether it's smart enough to compensate for system delays, I don't know. However, if it's running on a third machine from the two under test, it should time stamp the packets from each machine with more or less the same time offsets due to packet processing. This means that ideally, you want no other apps running on the ws machine, or, ie: minimum system load to get the lowest jitter on timestamp results. Have run it on P3/500 class machines, but suspect that it really needs p4 1.5Ghz or xeon 2.8 class machine to get the best result for the sort of problem you are trying to crack.

I used tcpdump on unix for years and still do from time to time, but it's command line only. ws has a very powerfull front end gui and has some serious commercial backing as well, even though it's still a free download.

You know the saying: use all available tools :-)...

Regards,

Chris

Reply to
ChrisQ

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.