AnsweredAssumed Answered

vrf I/O bottlenecks (Was: We want to entertain you for

Question asked by VRFuser on Oct 12, 2004
Shawn Fessenden wrote the following:
>>but I reckon that TCP/IP is faster
>>(100Mbps on TCP/IP vs 750kbps on GPIB).
>
> One would think so, but then again what protocol is the scope using. If it's
> standard TCP (proto 6), there's still overhead. Figure in all the control
> bytes & ACKs & NAKs & retries... 100M can start to look like not quite 100M!
> In fact any proto will have overhead. I don't think there's all that much,
> and there's going to be some overhead on the GPIB too, but at least that's a
> parallel bus.
>
> Maybe put a sniffer on it and see what all is going on. Ethereal is
> awesomely helpful, but anything that can break out packets would be cool.

As far as I'm aware it's standard SICL over TCP/IP.  I'm not sure about the
overheads etc.  Another slight complication is that the client and server are on
the same machine, so I'm not sure if the general methods for checking network
traffic are valid.  Where in the machine does it realise that the packet is
coming back to this machine?  Is it on the LAN hardware, PCI hardware or does
the kernel realise and just send it to the appropriate software?  Or does it get
as far as my router and then do a U-turn!?  I suppose I've got a similar
question for GPIB, as the master and slave are on the same physical interface
(different virtual interfaces).

>>I would like this second mode to run as fast as
>>possible (within the limitations of Windows XP).
>
> Well, between 100 & 500 per trig doesn't sound so terrible. How fast is the
> trigger? (Oh, yeah! As fast as possible.)

Ideally, the trigger is going to be around 1kHz, but I know this is simply not
possible to achieve reliably without dedicated hardware.  It is easily
achievable in the single shot mode as the scope hardware does all the work and
then passes it back, but the duty cycle of measurement time to data transfer
time is extremely low and I can't get the two to overlap!

> And yes - it is going to be an IO
> bottleneck. XP can go really fast if it has to. FWIW I'm also seeing more
> TCP/IP delay than I'd like to, though it has nothing to do with
> instrumentation.
>
> Can the scope be switched to a datagram mode? I'm sure an entire capture
> would be too large to packetize, but if it could send out individual points
> over UDP that would help.
>
> Or if it could just be set to send after capture. So you don't have to
> actually tell the thing to send data, just have it do so. You could start up
> a server thread whose whole purpose in life is to just sit there and wait
> for the scope to send data, then grab it and queue it up in memory for VEE
> to chunk when it has time. As soon as it's done storing data have it send
> another trigger. That would keep things rolling pretty darn quick.

No datagram mode that I can find.  And I can't see any way of getting the scope
to actively send data that it has collected.  It's a bog-standard Agilent method
of WRITE "DATA?" then READ x.

As I said originally, an API to the scope program would perhaps be the ideal way
to figure this one out.

--
Graeme Hilton
Product Engineer

Schlumberger Sensa
Gamma House, Enterprise Road,
Southampton, SO16 7NS
Tel: 023 8076 5596
Fax: 023 8076 5501

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list,  email "vrf@agilent.com". 
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".

Outcomes