Help How to achieve 1kb in 10 microsec

Depending on the source of your datastream a data analyser or even a simple storage oscilloscope comes to mind.

Both would allow you to capture the data and (later) transfer it into something usable. At a pace even Windows can handle :-)

That's peeking at in my book. Not capturing :-)

snipped-for-privacy@yahoo.com wrote in part:

Even without any overheads this is 100 Mbyte/s (0.8 Gbit/s). This will be _extremely_ hard to achieve. Forget PCI busses, and you may well need 10Gbe.

Counting in these latencies are what make it _extremely_ difficult even though it might look like GBE would be more than enough.

You probably need 10Gbe since GBE will take 8us just for transmission. Even a PCI66 bus isn't much faster and you have to transfer the data from RAM across the bus, down the wire and from the card across the bus back to RAM. Raw, that sounds like at least

24us if the OS/CPU can keep up. Which I very much doubt since interrupt latency is likely at least 1-5 us on MS-Win2k (Linux & FreeBSD APIC is much better, and MS-WinXP pro might have APIC).

If GBE is going to have a chance of working, you will have to look carefully for chipsets that can stream data both ways (busmaster directly) without buffering it (full load packet before sending).

If you cannot, then you might need to break the data into smaller packets (200-500B) and accept the overhead to reduce latency.

I would suggest MS-DOS (or MS-Win98se as the least bad DOSish MS-Windows). This can run in x86real-mode and avoid a lot of task switch and protection latencies.

Nothing standard, I'm quite sure. You may have to write asm polling no-copy drivers. I don't think you can afford a standard protocol stack, but might be able to on a fast CPU.

No surprise. The OS cannot keep up and drops interrupts.

This sounds about right.

-- Robert

One of my co-workers (who -is- technically minded) mentioned to me a few days ago that another of my co-workers is getting about 0.8 Gbit/s with ftp between two AMD Athalon server-type systems. That's over all overheads.

If the figure has reached me correctly then; A) it wasn't Windows; and B) it would be a -throughput- measure, not an elapsed-time measure.

I would have to investigate to find out whether it is PCI based. It is, though, 1 GbE.

I haven't been following too closely, but I thought I saw someone posting a few months ago indicating that at 10 GbE the minimum packet size increases quite a bit and that various other parts of the protocol have different timing. IIRC, 10 GbE is not just 1 GbE run 10 times faster.

2 GbE might be a possibility if 1 GbE is not quite fast enough. Or 2 parallel 1 GbE links with a 576 byte packet each ;-)

Am I interpreting things correctly that you want to exhange 1KB of data each way bewteen two machines and have that take only 10 microseconds?

Or do you simply mean have 1KB of data transmitted in less than 10 microseconds from one end to the other?

FWIF, you might want to look at any interrupt coalsecing parms on your NIC(s). The defaults are often selected with a mind toward minimizing CPU utilization for bulk transfers rather than minimizing latency.

And while that may make things better, I'm not sure I've seen anything get down to 10 microseconds request/response latency that still involved IP and UDP or TCP, and it has been a very long time since I've played with netperf link-level request/response stuff.

For that low a request/response latency you may need to consider stuff like Myrinet/Quadrics/rDMA etc etc.

rick jones

Quadrics/elan4 can provide this kind of latency. Fast opterons can easily sustain a 1k ping-ping in