Slow File Transfer From 16 Bit Application

[Guest]

Hello,

I am running a Windows 2003 Storage Server with teamed NICs on a gigabit
switch and a Windows XP SP2 client with a single 10/100 NIC. I have a 16Bit
application that I run from this box that moves files back and forth across
the wire, and it is very slow UNLESS I start a Windows file copy from the
client to the server, then the 16Bit app is the fastest I've ever seen it.
But once the Windows file copy stops, the 16Bit app slows back to a crawl.

Any Ideas?

Thanks,
Jeff

 

[Herb Martin]

Hello,

I am running a Windows 2003 Storage Server with teamed NICs on a gigabit
switch and a Windows XP SP2 client with a single 10/100 NIC.

Are these true "teaming" NICs with a teaming NIC driver
that substitutes a virtual (or teamed) NIC for the multiple
physical devices

I have a 16Bit
application that I run from this box that moves files back and forth across
the wire, and it is very slow UNLESS I start a Windows file copy from the
client to the server, then the 16Bit app is the fastest I've ever seen it.

What precisely do you mean by "start a file copy"?

Perhaps that is authenticating against the IPC$ share
and if you were to explicitly authenticate there that
would also "fix" the problem.

I am not really suggesting this would truly fix it but
it would be an interesting data point and might be
more convenient (temporarily) while you look for the
real problem....

net use \\Servername\IPC$ * /useromainName\UserName

[Substitute appropriate names for Server, Domain, User. ]

But once the Windows file copy stops, the 16Bit app slows back to a crawl.

It does seem odd so we are likely missing something...

Maybe services packs or a flaky switch are involved.

How precisely does the 16-bit app do a "file copy"?

SMB, HTTP, etc????

 

[Guest]

These are true teamed Broadcom NICs using a virtual NIC for two physical NICs.

By starting a file copy I mean dragging and dropping a folder from the
client to the mapped drive on the server

I can't connect to the IPC$ share with this app. Its hardcoded to look for a
specific drive letter when running.

The 16bit app utilizes BTRIEVE 5.10a to manipulate files on the server - not
exactly sure how it works but I know it calls btrieve before loading

Thanks,
Jeff

Hello,

I am running a Windows 2003 Storage Server with teamed NICs on a gigabit
switch and a Windows XP SP2 client with a single 10/100 NIC.

Are these true "teaming" NICs with a teaming NIC driver
that substitutes a virtual (or teamed) NIC for the multiple
physical devices

I have a 16Bit
application that I run from this box that moves files back and forth across
the wire, and it is very slow UNLESS I start a Windows file copy from the
client to the server, then the 16Bit app is the fastest I've ever seen it.

What precisely do you mean by "start a file copy"?

Perhaps that is authenticating against the IPC$ share
and if you were to explicitly authenticate there that
would also "fix" the problem.

I am not really suggesting this would truly fix it but
it would be an interesting data point and might be
more convenient (temporarily) while you look for the
real problem....

net use \\Servername\IPC$ * /useromainName\UserName

[Substitute appropriate names for Server, Domain, User. ]

But once the Windows file copy stops, the 16Bit app slows back to a crawl.

It does seem odd so we are likely missing something...

Maybe services packs or a flaky switch are involved.

How precisely does the 16-bit app do a "file copy"?

SMB, HTTP, etc????

 

[Herb Martin]

These are true teamed Broadcom NICs using a virtual NIC for two physical NICs.

By starting a file copy I mean dragging and dropping a folder from the
client to the mapped drive on the server

I can't connect to the IPC$ share with this app. Its hardcoded to look for a
specific drive letter when running.

As for IPC$, I mean to do that explicity from a
command line.

The 16bit app utilizes BTRIEVE 5.10a to manipulate files on the server - not
exactly sure how it works but I know it calls btrieve before loading

Interesting. I am (or at least was) a Btrieve programmer.
It was a excellent PC database until Novell bought the
product and ruined the IBM/Windows version to kill the
competition.

I know they eventually bought themselves out from under
Novell but by then it was too late to resurrect their reputation
and the product.

BTrieve had a lot of quirks on IBM/MS networks, what sort
of file copy does it do? Do you have source?

This is likely a BTRieve quirk issue.

 

[Guest]

I have run the app over a couple of different switches and a direct
connection between the client and the server via a crossover cable, all with
the same result - slow performance. For some reason I cant get the app to
transfer even close to wire speed unless I have some traffic in the
background. I have no idea what else to try as I dont have a btrieve
background.

 

[Herb Martin]

I have run the app over a couple of different switches and a direct
connection between the client and the server via a crossover cable, all with
the same result - slow performance. For some reason I cant get the app to
transfer even close to wire speed unless I have some traffic in the
background. I have no idea what else to try as I dont have a btrieve
background.

Were I in your fix then (one of) my next step(s) would be to
run NetMon or another sniffer to watch what happens.

Consider this (you probably have):

Something is different (better) when there is traffic -- this is
counter-intuitive since more traffic should make for slower
transfers if they are noticable at all.

So what can a current transfer change?

These come to mind immediately:

1) Authentication -- which should last longer than a single
transfer. I would only expect this to make sense IF you
saw improvement after any transfer even if it ended.

2) Switch/hardware problems

3) Application specific

My guesses bets come down to two WEAK hypotheses:

1) Transferring data is keeping the switch path open
(related to switch problems)

2) The application is somehow flushing the name table
(unlikely) and then broadcasting to resolve names
but with the other app (transfer) running it stays
populated. -- I don't really like this.

I would probably focus on the switch itself.

What type of switch is it? Layer-2, Layer-3, VLAN?
Same subnet or different?

Did connecting MANUALLY to IPC$ show a difference?