Agilent 16702A network speed poor.

[BinaryDinosaurs]

Hello all,

Trials and tribulations with my 16702A continue. Recently I did a successful 2M capture of a device and wanted to transfer the resulting ~200mb file to my iMac for further analysis. I still have machines capable of plain old FTP so I set a transfer away thinking it would take 10-15 minutes. 45 minutes later I killed it because something can't be right. Next I tried NFS and that fails instantly with an ESTALE error, stale file handle. This is weird because I can happily mount a filesystem, cd to it and create a file, then delete the file. But copying eg a small core dump just fails, or will sit and LOOK like it's doing something but in fact isn't. Usually for that sort of issue I'd look for hp/ux patches and have got a patch CD for 10.20, but in all my reading here I've never seen anyone talk about doing this.

Next I tried CIFS to an XP box that would accept the connection. I could copy small files no problem, but again the ~200mb file took over 45 mins before I killed it - it was writing but would've taken hours at the speed it was going.

I wondered if it was autonegotiation with the old HP switch it's plugged into, and I thought it was strange that it autonegotiates to 10mb half duplex. Surely even in 1999 full duplex 10baseT was the norm. I mean, I was there and I'm sure 10 or 100FDx was a thing I was using. I can't see any way of changing between HDx and FDx in the config though. Somebody suggested putting a terminated t-piece on the 10base2 plug in case it was causing noise, which I've done. Next thing I guess is to pull out a 10/100 switch and hook it up to that instead. BTW I did set the HP's switch port to 10FDx and could log into the analyser, but when I tried to start vp over X nothing happened.

Am I just expecting too much?

Cheers
Adrian

[aeg]

There's something wrong with your network. Maybe your client is sending packets through NAT or has a hypervigilant firewall, preventing the data socket from opening. Setting the FTP client to passive mode may help. Otherwise, troubleshoot with traditional methods (tcpdump...)

NFS interoperability with HP-UX is problematic. Be sure to force NFSv2, but that may not be enough.

Here is the throughput I get from FTP with a Linux client against a 16702. This is a 16702B, which has a faster CPU, and 100-megabit Ethernet. But clearly it's not taking 45 minutes...

Code: [Select]

$ curl -o /tmp/foo ftp://ftp@sargon/gcc-4.2.2-10.20.sd
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  379M  100  379M    0     0  3895k      0  0:01:39  0:01:39 --:--:-- 3866k


[BinaryDinosaurs]

Yeah I've long suspected something is up with my wifi which takes the rest of the network down sometimes, but not consistently. My workshop is at the end of a Mesh link back to the house and all the test gear is in here. I'm now using wired for further testing, and my test file of 215mb did copy over much quicker. However, the real slowness is printing to a file. The whole reason I started down this route is I have a blueSCSI in the mainframe instead of spinning rust, and it seems to run without errors though the X session and telnet sessions pause fairly frequently which looks like a possible bus reset occurring. If I put logging on the blueSCSI though it's happy and doesn't report timeouts or restarts.

Printing to a file locally also takes 45 minutes+ which is why I started looking at NFS or CIFS - surely writing to the network is quicker. Maybe not in my case 

Tomorrow I'm going to try and find some 9GB SCSI drives at work. They'll need an SCA adapter but I happen to have one of those. At least then I'll be able to rule out the blueSCSI as being at fault.

[BinaryDinosaurs]

OK this was kind of as expected, so it's only printing to disk that's slow.

Code: [Select]

adrian@gaspode:~# curl -o /tmp/foo ftp://adrian@hex/wtDumpFrom0A0A.txt
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  205M  100  205M    0     0   940k      0  0:03:43  0:03:43 --:--:-- 1107k

[gslick]

Yeah, printing a state listing to a text file on a 16700-series for offline analysis can be painfully slow. For example, if you have a 2M deep state sample capture with an inverse assembler enabled, printing the entire capture to text file on disk can easily result in file in the 100-200MB range, and that is in the category of start the print to disk operation and then plan on doing something else for an hour while it finishes. And better hope you don't realize when it's done that you need to redo the capture and do the whole thing over again.

People can hate the Windows based logic analyzers all they want, but this is one of areas where the Windows based 16800/16900-series logic analyzers can put the 16700-series to shame and complete the same print to disk operation in a completely reasonable amount of time.

[BinaryDinosaurs]

This is exactly what I did yesterday - 8085a listing with Invasm - and realised when it was nearly done that I hadn't applied the new symbols I'd pulled from the source listings. 46 minutes it took, 310mb.

I rescued a couple of 18gb SCA disks this morning just to see if I could create a 4gb partition on one and use the BlueSCSI in initiator mode to transfer the disk image I'm booting from back onto a real disk, or just try re-igniting onto a real one to see if it chokes or not. Possibly not worth the time based on what you're saying, it's just slow no matter what.

Thanks, as ever, for the heads-up!