> -----Original Message-----
> From: Ed Wilts [mailto:ewilts AT ewilts DOT org] 
> 
> You're not alone...  I've seen it with Windows and VMS clients and
> writing to an L700 with SDLT220 drives.  We've seen on both 
> our Solaris
> 9 master/media server and a Win2K media server.

Oh well...nice to know it's not just me.....not just our specific
config, either.
Damn hard to explain to clients though.
We just trasitioned from CA Arcserve to NB, and we're getting a lot of
"We didn't have this problem with Arcserve".....Luckily for them they
probably never requested a restore from the old system.
At least with NB, if we can get it backed up, we can usually restore it.
;o)

> Yup - it really sucks.  Manually restart the job and it starts to fly.

*nodding*

> I don't actually know how often happens to us since it's just a normal
> backup that we happen to spot running really slowly.  

Really? Randomly throughout your environment?
I my case, it's pretty obvious...i get in at 08:00 and there are 3 jobs
running.....the stalled job, and the Vault and Duplicate jobs that are
stalled waiting for this stalled job to complete, so the vault run can
finish....I saw one stall this morning that wasn't behind the firewall,
but the one today is also running the same app that the 4 servers behind
the firewall are running. Coincidence??

> We're seeing this on clients with GigE connections that aren't behind
> firewalls.

Hmmm...if I launch a manual on a newly deployed box and get this 25KB/s
throughput, I can make an educated guess that it's a NIC speed mismatch
(switch port set to 100FD and GigE NIC set to auto/auto) and 95% of the
time, I'm right, but in the case of these servers, that definitely isn't
the case. 

> 
> I haven't found the problem yet but it sure be nice to know 
> what it is!

If you (or anyone!) ever figures out what it is....please post up!!!

Paul