NASLite Network Attached Storage

Hello,

i have a problem with my naslite+.
When i send a file to my naslite, the speed is very good. 1 gb 6 - 8 minutes.
But when i get a file from my naslite, i have for the same file 80 - 100 minutes!!

Can someone help me?

thanks a lot

Hi,

Could you post details of your hardware for both machines. and your networking set-up.

Eden

Processor (CPU)
vendor_id : GenuineIntel
model name : Pentium III (Coppermine)
cpu MHz : 863.876
cache size : 256 KB
bogomips : 1723.59


--------------------------------------------------------------------------------
Memory
total used free shared buffers
Mem: 255896 251704 4192 0 1580


--------------------------------------------------------------------------------
Disks
Filesystem Size Used Available Use% Device
System 7.7M 3.7M 4.1M 47% RAM Disk
Storage Area 73.4G 1.2G 72.2G 2% NAS Disk-3


--------------------------------------------------------------------------------
Network Interface
RealTek RTL8139 at 0xd0800f00, 00:30:84:3c:d8:8a, IRQ 5
Identified 8139 chip type 'RTL-8139C'
link up, 100Mbps, full-duplex, lpa 0x45E1
Link encap:Ethernet HWaddr 00:30:84:3C:D8:8A
inet addr:192.168.1.87 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:908015 errors:0 dropped:0 overruns:0 frame:0
TX packets:517560 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1289606847 (1.2 GiB) TX bytes:137848819 (131.4 MiB)
Interrupt:5 Base address:0xf00



The other Pc is a 2200+ Asrock motherboard and 768 mb ram

First I would isolate the problem.

Get a known GOOD crossover cable and plug you NASLite box directly into the other computer bypassing any hubs, switches, routers.

the transmit and receive lines on cat5 cable are seperate and I have seen them in the past cause problems if the impedance, capacitance, etc gets out of spec on one of the lines. ie fast/slow transmit/receive while not drastically effecting the other.

If it is still slow tested directly with a known good crossover cable then you might try swapping out the NIC, etc.

I was also getting exactly this problem until today. I'd even been experimenting with Debian and OpenFiler as potential replacements, with no success. I'd love to learn Linux, but I just don't have the time or know quite where to begin ...hence the choice of NasLite in the first place.

I tested the cable theory mentioned above with the other machine on my desk (a G4 Mac on OSX). I found this was reading and writing at full speed. Both cables worked there. I flipped the cables about in my 10/100 switch too in case it was an issue with the switch. Again no change.

So I ruled out cabling issues (vindicating my cable making skills, hooray)

Next I checked for updated drivers for my problematic machine: None on the nvidia site (nforce2 chipset). However Windows update, which I usually shy away from, saved me! It suggested the SATA RAID controller (not covered by the nvidia updates... doh, silly me!) driver had a new driver available. As soon as that was updated, reading a 60MB file from my NASLite+ box no longer took 4 mins, but the 5-10secs I was hoping for.

Long story short : Check your drivers are up to date on the machine you're experiencing problems with. If possible compare read/write rates on another machine.

:)

<Edited for typos>

Hi Foci

I could imagine that you have the same problem as I had. One way fast, the other slow.

Can you check if SMART is still running? As long as this "thing" is running (takes over an hour for me) the diskperformance is extremely slow. As soon as its finished its super fast (7mb/s and 11 mb/s)

So, I thought everything was fine. I updated my SATA drivers for windows and everything whizzed along.

Then today I moved a 30MB file from my NASLite+ box to my XP machine. 1 minute later I was still waiting.

Send the same file back... 3 seconds. Done.

So, I rebooted. copied the file to my local desktop, 3 seconds. Done. Immediately hibernated the computer. Resumed from hibernation...tried to copy the file again. 3 minutes... Rebooted, used sleep instead of hibernate, same problem: super-long read times.

This leads me to believe that it wasn't the driver upgrade which sorted things out in the first place. Instead, the reboot was probably the thing that did it.

Clearly this problem isn't NASLite's fault, but can anyone suggest what the issue might be here? Why does network performance take such a nosedive after using hibernate? I'm using an ABit NF-7S motherboard, which utilises an nVidia nForce2 chipset with built in 100Mbit ethernet.

Any thoughts gratefully received.

Hello Catflavor:

I've had a few very strange symptoms related to hibernate mode over the years, except on laptops. Hibernate is a great idea, but poorly executed by Microsoft. The laptop vendors seem to pay special attention to this MS O/S feature and do more compatibility testing, often providing their special integrated versions of power options and control. Desktop mobo vendors don't have/can't spend the time to do this much testing, instead relying on MS ... but MS can't anticipate the huge selection of hardware combinations ... you get the idea.

Best advice on desktops is to stay away from hibernate.

But in the interest of trying to debug your issue a bit further:

1] After a return from hibernate try using the "repair" function in your network settings (easiest way to get to it is to double-click on the LAN icon (two side-by-side computer monitors in the system tray), choose the "Support" tab, and click "Repair"). I think the hibernate messes up the NIC (and the drivers that control it and the suspended network operations).

2] If your desktop uses DHCP ( I don't ... I use fixed IP addresses ) hibernate may cause even more confusion. When it resumes it's lost its place in your network.

3] Your page file and hibernate file setup may contribute to the problem. One of the early things I always do on a new WinXP install is to a] disable page file; b] disable hibernate (in Control Panel/PowerOptions); c] reboot; d] defrag (several times using the Windows built-in function; or only once with better 3rd party tools that result in better compression); e] set page file to the SAME Initial AND Maximum size (explanation below); f] enable hibernation; and then just for fun to prove the point, g] defrag again resulting in two large green blocks (unmovable files, one each for Paging, the other for Hibernation). For page file size I choose 1.5x or 2x RAM using a proper 1,024 byte multiple (1GB RAM = 1,536MB or 2,048MB page file).

Reasons for initial=maximum page file size: If you don't do this, as the page file grows beyond its initial size, it is *automatically* guaranteed to be fragmented. I have no proof of the following, it's just a hunch, but when your system comes out of hibernation (which restores the hibernation file from disk back to RAM (and if that file is also fragmented ... who knows what bugs MS has in the code) then the restored RAM may have lost track of the paging file data. And since many prefetch data is in there ... (Ignore the explanation if this is all too technical ... but follow my a]-g] procedure above anyway.)

Post back any results/improvements you see ... I'm curious.

Georg

Thanks for the input Georg. Its been a busy week, so I haven't had a chance to check these forums until today, when I put your suggestions to the test.

I have my pagefile on a seperate disk to my system disk so it wasn't too fragmented and made defragging quick. But the pagefile wasn't a dedicated size, so I defragged the disk until it would defrag no more and set the pagefile to 4096MB.

Sadly a reboot, then a sleep/hibernate yielded the same results as before. Using repair on the ethernet connection didn't change anything either.

Just one question, does the hibernation function use pagefile.sys to store its data? You mentioned I should get two seperate immovable files in defrag, but I've only ever had one appear.

So, thanks for the suggestions, much appreciated. But they didn't have the desired results. I'll gladly try anything else you or others can think of which sounds plausible...

Hello Catflavor:

The hibernation file is C:\hiberfil.sys and its size should match the amount of RAM you have. Sorry to hear about your "un-success". Like my experience has shown ... desktops are not so good at hibernating.

Paging file being on a separate disk might help speed-wise (especially if it's on a different IDE or SATA channel than your C: drive), although it makes no difference fragmentation wise once you have fixed pagefile with min=max. In my case both hiberfil.sys and pagefile.sys are on C:, but for fragmentation (and speed) reasons I put all my TEMP & TMP stuff on a physically different drive, including InternetExplorer Temp files. (See "ControlPanel /System /Advanced /EnvironmentVariables" (in WinXP/SP2; SP1 is slightly different location). But be careful in changing these settings ... when you reboot ... if the paths are unavailable, problems happen.

But enough about Microslop already ...

Sorry I can't help further ...
Georg

You could always use pagedefrag from Sysinternals.com

At every boot it will defrag the pagefile, hibernation file, along with a few other files which can't normally get defragged

Best of all - it's free