Another new build problem.

S.T.F.U

S.T.F.U

S.T.F.U

Associate
Joined
7 Nov 2004
Posts
154
Location
Liverpool, England
Sorry guys need help with yet another problem. Since building my new rig I have noticed that when transferring files from my internal hard drive to a USB it's really, REALLY slow. For instance, In my last PC It would transfer 700mb file in about 60-70 second. Now we are talking about 3-5 minutes. I have tried plugging the usb drive into different ports and updated my USB3.0 drivers and it's not changed a thing. Anybody got any ideas? It is noticeably different to my last PC and that wasn't even USB 3.0...

Specs:

Gigabyte GA-Z77X-D3H (rev 1.0)
Corsair Force Series 3 F120 (120gb) 2.5 Inch Sata 3 Solid State Drive
PNY USB 8GB USB (2.0)
 
Last edited:
Anybody any ideas? I have notice that on the gigabyte website on there driver page for my motherboard under the USB section there is VIA USB 3.0 Driver and Intel USB 3.0 Driver. I'm using the Intel one at the minute, could that be the problem?

EDIT: Also something else probably worth mentioning is that when transferring the status bar will start off fast and once it reaches about three quarters of the way it's then that it slows to a crawl...
 
Last edited:
triggerthat said:
Try the latest Gigabyte drivers.
Click to expand...

I've done that mate, that was the first port of call. I can't really think of what else to do, I'm pulling my hair out here!

What I've done so far,

Uninstalled drivers
Reinstalled drivers with newest ones from Gigabyte
Tried different USB ports
Enabled Write-Catching in properties

Nothing has worked, only thing I haven't messed about with yet is Bios settings.

It's just took me 20 minutes to transfer a 2.5Gb file, it's ridiculous! :confused:
 
I've experienced a similar issue in debian. the last one percent takes ninety percent of the time. qq are the files being copied being used by another processor?

SoC
 
Thanks for the reply. I'm not entirely sure if the file is being used by another processor? How would I tell if it is? You nailed it here,

SoC said:
the last one percent takes ninety percent of the time.
Click to expand...

Thats also what seems to happen, the status bar will be at 100% and just stay there for a few minutes. Annoying isn't the word...
 
I have a similar problem when copying across the network to a local usb drive, was always quicker to copy to desktop and move files to the usb drive.

Can you reproduce the problem, adding in the step of copying to the desktop first then to the usb drive?

Maybe its antivirus software scanning the file as it finishes.

Edit: Indexing service maybe?
 
Sir SpankalotUK said:
I have a similar problem when copying across the network to a local usb drive, was always quicker to copy to desktop and move files to the usb drive.

Can you reproduce the problem, adding in the step of copying to the desktop first then to the usb drive?

Maybe its antivirus software scanning the file as it finishes.

Edit: Indexing service maybe?
Click to expand...

I also thought of it to be my Antivirus but I have disabled it and then started a transfer and it's still slow. I'll try disabling windows indexing and report back...
 
What I found was that copying multiple files at once was multiple times slower than individual copies - now you would expect the OS to do the smart thing but it would seem that it gets bits of the file from the disk platter which you can understand would slow things down. I think that the OS sometimes gets very inefficient at the task and forgets which file has has finished. That said, the kernel upgrade many moons ago has solved my issue but I never copy multiple files in parallel.

As long as you are not using the file in another application at the same time you are copying it should not have a lock.

That has got me thinking ... Have you defragged lately as you are using windows? If the file is big and really spread out on the disk platter it would make some kind of voodoo sense that you have the same issue?

SoC
 
I'm transferring the data from my SSD to USB. So that rules out a defragged drive, I must have tried everything by now. I'm going to throw it in the bin lol.
 
Don't worry ... I reckon it is a driver issue ... Just like it was with Debian.

SoC
Ps- I was using esata to resolve the issue until the kernel update resolved it for me :-)
 
You must log in or register to reply here.
Back
Top Bottom