AnsweredAssumed Answered

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

Question asked by VRFuser on Oct 13, 2004

Like • Show 0 Likes0
Comment • 4

Hi Graeme,
I would like to know if there are Agilent I/O Libs installed on the scopes WinXP and if you
have the possibility to install VEE. If so, you could use VEE's profiler for a direct compare
of the execution times.

I you say TCP/IP is implemented as SICL Lan or VXI-11 protocol, the Instrument string
should look like
TCPIP0::<scope_ip>::gpib0,8::INSTR which means the GPIB interface will be used
anyway.

Am I wrong ?

Best regards
Christian

Betreff:             Re: I/O bottlenecks (Was: We want to entertain you for
     Thanksgiving.)
Von:                 Graeme Hilton <GHilton@slb.com>
Datum:        Wed, 13 Oct 2004 11:34:59 +0100
Antwort an:          Graeme Hilton <GHilton@slb.com>

> Shawn Fessenden wrote the following:
> > Well that's twice now it's been echoed back to the whole **** list. Anybody
> > wanna go for three?
>
> I'll leave that for someone else. I'm sure Scott and Nicole will be jumping
> down the throat of Mr Mike Kugler, or his ISP, very shortly.
>
> You never know, we might all get a free Thanksgiving dinner
>
> Onto my problem of the day. I'm running a data capture program on an Agilent
> scope (8353A for those that are interested). The program runs in two modes.
> One mode captures 32.8 million data points off one trigger and then does some
> number crunching. The other mode captures between 100 and 500 data points on
> every trigger. I would like this second mode to run as fast as possible (within
> the limitations of Windows XP).
> The limitation at the moment seems to be getting the data off the scope memory
> and into the program. The runtime program runs on the scope (it's a scope with
> WinXP as the operating system. The program uses the TCP/IP address to talk to
> Agilent's Scope program. I also have the option of using GPIB, but I reckon
> that TCP/IP is faster (100Mbps on TCP/IP vs 750kbps on GPIB).
>
> Ideally I suppose it would be fastest to talk directly to the Scope program
> through some API, but I doubt Agilent are going to let that one out of the bag.
>
> If anyone has any ideas on how to acheive maximum data transfer rate, feel free
> to tell me!
>
> --
> Graeme Hilton
> Product Engineer
>
> Schlumberger Sensa

BIOTRONIK GmbH & Co.
EIT-1/CW
D 12359 Berlin - Neukoelln
Tel.: +49 30 689 05 - 4819
--------------------------------------
christian.wienhold@biotronik.de
--------------------------------------

---
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".

No one else has this question

Outcomes

4 Replies

VRFuser Oct 12, 2004 3:10 PM
Mark Correct
Correct Answer
> You never know, we might all get a free Thanksgiving dinner

Hey, even for $5 I'm in. I can drink an awful lot of booze

> 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.

> 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.) 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.
-SHAWN-

---
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".
Like • Show 0 Likes0
Actions
VRFuser Oct 12, 2004 9:21 PM
Mark Correct
Correct Answer
> As far as I'm aware it's standard SICL over TCP/IP.

Ah - yes I forgot about that part also. SICL. It *might* actually be better
to use the GPIB.

> Another slight complication is that the client and server
> are on the same machine

This Ethereal thing isn't hardware so no problem there. It's kind of a pain
to set up though. You have to install a filter driver first and then the
application. But it's really nice. It shows you everything, all nice and
neatly organized.

> Where in the machine does it realise that the packet is
> coming back to this machine?

In the TCP/IP stack. I don't know exactly at what level it filters, but from
it's output I think it probably sits just above layer 2 in the OSI model. It
might be above layer 1 though - the Data Link layer. It's awfully complete.

> does the kernel realise and just send it to the appropriate software?

Correct. Windows was designed with a very flexible driver model - meant to
compete with 'NIXs model. It got even better with the Windows Driver Model
introduced in W98/W2K. Software can actually insert itself into kernel
driver layers. Once such modification in a "driver stack" is called a
"filter driver". It's purpose is to modify or monitor the behavior of a
driver. The OSI model is implemented in a series of driver layers, so all it
takes to monitor it is another filter driver.

> but the duty cycle of measurement time to data transfer
> time is extremely low and I can't get the two to overlap!

That's kind of odd. I didn't read the data sheet, but I would have thought
the design would have included multiple processors. SHOCK! I see it doesn't.
Or at least it doesn't say so in the data sheet (I just went and looked it
up). So I guess basically it's only going to be doing one thing at a time
(from the CPU standpoint anyway). Still, it should be able to trigger
whatever data acq hardware it has and do IO at the same time. It has to have
some kind of acq internally.

> It's a bog-standard Agilent method of WRITE "DATA?" then READ x.

Oh my! Well it's not all that unusual an application. There has to be a
solution. Hmmmm... it says it's running XP Pro. And yet you're on XP also.
Nevermind. Just thinking out loud.

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

It might, but then again it might open up a huge can of worms. I can't
believe you wouldn't be able to do it without going to extreme lengths. Do
Les or Jay know anything about this scope?
-SHAWN-

---
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".
Like • Show 0 Likes0
Actions
VRFuser Oct 13, 2004 1:07 AM
Mark Correct
Correct Answer
Hi Shawn and the vrf,

> > Where in the machine does it realise that the packet is
> > coming back to this machine?
>
> In the TCP/IP stack. I don't know exactly at what level it
> filters, but from
> it's output I think it probably sits just above layer 2 in
> the OSI model. It
> might be above layer 1 though - the Data Link layer. It's
> awfully complete.

Note that if the address is localhost or 127.0.0.1 (I think that's the
right IP number. nslookup seems to think so too), it should make the
U-turn fairly quickly inside the network stack (software). However if
you provide your own full hostname or IP address (e.g. 123.124.125.126
or my.computer.com) it may make the U-turn later on in the stack
(slower), or may indeed make it all the way out to the router and come
back the same way, with vastly increased latency.

I don't know the above for petrified fact, but am reasonably sure it's
true. Shawn, thoughts?

Anyway, on localhost with 100base-T, I would be surprised if SICL-LAN is
not considerably faster than PCI-GPIB (assuming a very fast instrument)
in general. I'd also expect VXI-11 to be faster, though it probably has
to wade through more software than SICL-LAN, being standards-based.
Latency is what might cause slowdowns, especially for numerous small
IOs. But 10base-T might be slower than PCI GPIB, especially with small
IOs.

As for our friend the turkey man, Nic and I are looking into it. Nic's
en route to VEE Days Chicago, and she has the key to the weapons chest
so I'll need to wait for her to get to a hotel with networking available
before I can pull the pin on an email-grenade.

Best Regards,

Scott Bayes
Software Technical Support

Agilent Technologies, Inc.
815 14th Street S.W.
Loveland, CO, U.S.A. 80537

970 679 3799 Tel
970 635 6867 Fax

> -----Original Message-----
> From: Shawn Fessenden [mailto:shawn@testech-ltd.com]
> Sent: Wednesday, October 13, 2004 11:21 AM
> To: VRF
> Subject: [vrf] Re: I/O bottlenecks (Was: We want to entertain
> you for Thanksgiving.)
>
> > As far as I'm aware it's standard SICL over TCP/IP.
>
> Ah - yes I forgot about that part also. SICL. It *might*
> actually be better
> to use the GPIB.
>
> > Another slight complication is that the client and server
> > are on the same machine
>
> This Ethereal thing isn't hardware so no problem there. It's
> kind of a pain
> to set up though. You have to install a filter driver first
> and then the
> application. But it's really nice. It shows you everything,
> all nice and
> neatly organized.
>
> > Where in the machine does it realise that the packet is
> > coming back to this machine?
>
> In the TCP/IP stack. I don't know exactly at what level it
> filters, but from
> it's output I think it probably sits just above layer 2 in
> the OSI model. It
> might be above layer 1 though - the Data Link layer. It's
> awfully complete.
>
> > does the kernel realise and just send it to the appropriate
> software?
>
> Correct. Windows was designed with a very flexible driver
> model - meant to
> compete with 'NIXs model. It got even better with the Windows
> Driver Model
> introduced in W98/W2K. Software can actually insert itself into kernel
> driver layers. Once such modification in a "driver stack" is called a
> "filter driver". It's purpose is to modify or monitor the
> behavior of a
> driver. The OSI model is implemented in a series of driver
> layers, so all it
> takes to monitor it is another filter driver.
>
> > but the duty cycle of measurement time to data transfer
> > time is extremely low and I can't get the two to overlap!
>
> That's kind of odd. I didn't read the data sheet, but I would
> have thought
> the design would have included multiple processors. SHOCK! I
> see it doesn't.
> Or at least it doesn't say so in the data sheet (I just went
> and looked it
> up). So I guess basically it's only going to be doing one
> thing at a time
> (from the CPU standpoint anyway). Still, it should be able to trigger
> whatever data acq hardware it has and do IO at the same time.
> It has to have
> some kind of acq internally.
>
> > It's a bog-standard Agilent method of WRITE "DATA?" then READ x.
>
> Oh my! Well it's not all that unusual an application. There
> has to be a
> solution. Hmmmm... it says it's running XP Pro. And yet
> you're on XP also.
> Nevermind. Just thinking out loud.
>
> > As I said originally, an API to the scope program would perhaps
> > be the ideal way to figure this one out.
>
> It might, but then again it might open up a huge can of worms. I can't
> believe you wouldn't be able to do it without going to
> extreme lengths. Do
> Les or Jay know anything about this scope?
> -SHAWN-
>
>
> ---
> You are currently subscribed to vrf as: scott_bayes@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".
>

---
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".
Like • Show 0 Likes0
Actions
VRFuser Oct 13, 2004 3:02 AM
Mark Correct
Correct Answer
This is driving me nuts. I've spent way too much time on it. Can anyone tell
me why I get .562000000000000001 instead of .562 when I convert the number to
text (see attached VEE Pro 7.0 program)? Also, do you have any idea how to fix
this problem?
Regards,
Lee

Lee Hudson, R&D Scientist
**************

Sure.

You get .562000000000000001 becuase that's the precise answer that
IEEE standards call for. Since this is a digital computer it
only has so much precision and can therefore only approximate
most numbers. That is, since you only have 64 bits to work with
for IEEE 64-bit floating point there's only a fixed subset of
the real numbers that can be represented. Everything else is
approximate- hence the origins of what you are seeing.

Many environments choose to hide this. VEE ( for better or worse)
decided to expose it.

If you want less precision then it is just a case of number fomatting,
and one of the best ways to do that is to use a To String object
so that you can specifiy whatever format/precision you like.

Stan

--------------------------------------------------------------------------
Stan Bischof Agilent Technologies 707-577-3994 stan_bischof@agilent.com
--------------------------------------------------------------------------

---
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".
Like • Show 0 Likes0
Actions

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

Outcomes

Related Content

Recommended Content