Thanks, Thane. Hadn't thought of that. I'll let you guys know what
happens, but from the speed that they are looking into this, I wouldn't
expect any news soon. I've been told that other people in other
divisions have this problem, then again, these guys like to make up
stories. I will put forward the idea that maybe they need to restart
the router, but then again, I don't know how they've architetured the
building. And thanks for confirming that low disk space is most likely
not causing the problem.
On 11/9/2021 6:55 PM, Thane K. Sherrington wrote:
Hi Steve,
I'm assuming he means anti-virus, which is a possible culprit for
sure. It could also be a routing issue if your routers are
misconfigured.
On 08-Nov.-2021 9:13 p.m., Steve Tomporowski wrote:
Greg,
What do you mean by 'Could be A/V as well'? I don't think you mean
A/V to mean audio/visual. LOL Incidentally, one of the things the
local guy did was put PrimoCache on my computer. It didn't work
because it doesn't reach across a network.
Steve
On 11/8/2021 8:08 PM, Greg Sevart wrote:
It *is* possible that running low on disk space could slow down
transfers. For example, TLC/QLC disks typically have a portion of
the NAND that they use in a type of "SLC-mode" cache to mask the
vastly slower writes inherent to TLC/QLC - but if the disk is nearly
full, some of them will have to abandon that strategy. SMR rust
spinners can sometimes be similar if they use some CMR tracks as a
cache. So, it is indeed possible that nearly full disks can impact
performance, but I doubt that's the issue. It seems more likely to
me that the initial copy is being put into a memory buffer, then
it's having to slow way down as that buffer is filled or it's
finalizing the transfer. Could be A/V as well.
I'm currently rebuilding some of my home fileservers and am
experimenting with a piece of software called PrimoCache. The idea
is that it will let you put either a memory or a SSD cache in front
of big, slower rust spinners. I've sized my cache (in this case,
800GB of enterprise-class SAS3 SSDs in a RAID10 fault-tolerant
arrangement in front of 64TB of spinners) such that any normal
transfer should fit within that cache, but if I do exceed it,
performance definitely does slow down. I'm planning on using DFS-R
to replicate to an offsite fileserver for additional fault tolerance.
-----Original Message-----
From: Hardware <hardware-boun...@lists.hardwaregroup.com> On Behalf
Of Thane K. Sherrington
Sent: Monday, November 8, 2021 4:28 PM
To: hardw...@lists.hardwaregroup.com
Subject: Re: [H] Slow Network Transfers
So this is an internal link? What is the link speed? When you
check taskmgr, what is your network utilization?
It sounds to me like an overloaded link or a switch issue.
Never heard of slow transfers due to low disk space.
T
On 05-Nov.-2021 5:13 p.m., Steve Tomporowski wrote:
Ok, I need some advice from people I trust. The company I work for
had transitioned from in-house IT to Bell Technologies, so we
obviously swimming in 'tickets'. We have a main data drive on the
network, the 'K' drive and I've had a ticket in for about 8 months now
on slow transfers. The symptoms are this: When transferring a number
of files from a laptop/desktop, there will be data transfer for about
1 to 2 seconds, then 20 to 30 seconds of nothing. Rinse and repeat.
I've also noticed that if you transfer a single file, most of the time
it will transfer 99%, then you have 20 to 30 seconds of waiting until
it finishes.
Now to the question. I've just been told that slow transfers happen
when there is low disk space. Obviously we have a lot of users
accessing the network drive but the slow phenomenon wasn't present
some time ago and has been persisting for a couple of years now. Is
this third-party IT organization correct or blowing smoke. I have
been lied to before by them.
Thanks...Steve
