PDA

View Full Version : Slimserver is woeful on Windows



egd
2007-02-23, 22:55
I've just rebuilt a w2k3 machine and installed SlimServer 6.5.2 - 11509 - Windows Server 2003 - EN - cp1252. Accompanying it is
Perl Version: 5.8.8 MSWin32-x86-multi-thread and MySQL 5.0.22-community-nt

I have a large FLAC library (~50k songs) but damnit, it shouldn't take hours to scan just because it is located on a NAS, especially not when the same library scans in under 20 minutes under Linux. I'm annoyed that I started a scan operation ovr four hours ago, came back to the house after being out for most of the afternoon only to find the damned thing is still scanning - with scanning set to highest priority.

What gives, any ideas?

erland
2007-02-24, 01:41
I have a large FLAC library (~50k songs) but damnit, it shouldn't take hours to scan just because it is located on a NAS, especially not when the same library scans in under 20 minutes under Linux. I'm annoyed that I started a scan operation ovr four hours ago, came back to the house after being out for most of the afternoon only to find the damned thing is still scanning - with scanning set to highest priority.

What gives, any ideas?
Do you have any playlists that might contain references to music files that no longer exists or have been moved to another drive/directory ?

egd
2007-02-24, 13:46
Do you have any playlists that might contain references to music files that no longer exists or have been moved to another drive/directory ?

I'm afraid not. Thanks for the suggestion though.

aubuti
2007-02-24, 15:41
There were some posts in the past month or two about the same problem, ie, appallingly slow scanning with Windows on a network drive. I can't remember if it was scanning a NAS or just a drive on another computer. I did a quick search for the thread and couldn't find it. You might try a more in-depth search, or check bugzilla to see if a bug has been filed.

JJZolx
2007-02-25, 02:30
I've just rebuilt a w2k3 machine and installed SlimServer 6.5.2 - 11509 - Windows Server 2003 - EN - cp1252. Accompanying it is
Perl Version: 5.8.8 MSWin32-x86-multi-thread and MySQL 5.0.22-community-nt

I have a large FLAC library (~50k songs) but damnit, it shouldn't take hours to scan just because it is located on a NAS, especially not when the same library scans in under 20 minutes under Linux. I'm annoyed that I started a scan operation ovr four hours ago, came back to the house after being out for most of the afternoon only to find the damned thing is still scanning - with scanning set to highest priority.

What gives, any ideas?

Do you mean has anything new emerged since you asked the same question a month ago? Why not go back to running SlimServer under Linux?

http://forums.slimdevices.com/showthread.php?t=31844

My experience (and apparently yours as well): A Windows SlimServer with an Infrant NAS for file storage is a BAD/SLOW/BROKEN combination. There's something going on there with network file access between the two systems that just doesn't jive. Whether the issue is limited to file shares on just the Infrant system or is more general is something probably worth looking into.

File a bug report and maybe someone will look into it.

erland
2007-02-25, 05:20
Is it faster if you run a PC with Linux and connect that to the NAS ?

Or are you just saying that SlimServer locally installed on the NAS itself is faster ?

Paul_B
2007-02-25, 05:26
My setup on Windows 2003 R2 doesn't cause any problems or performance issues. It is wired from W2K3 server to QNAP NAS storage and SB3. A complete rescan of my 5,000 tracks is fine. Any issues with NIC settings on network speed and duplex? It is standard practice to always force this rather than leave it at auto/auto

egd
2007-02-25, 06:19
Do you mean has anything new emerged since you asked the same question a month ago? Why not go back to running SlimServer under Linux?

I guess I was hoping that something would have changed in recent builds of 6.5.2 for Windows. I would love to go back to Linux but had a drive hardware fail on that box and I'm still recovering data from the drive which is a slow process. Once that's complete I will most definitely be returning to Linux. Don't even get me started on backups... :[


My experience (and apparently yours as well): A Windows SlimServer with an Infrant NAS for file storage is a BAD/SLOW/BROKEN combination. There's something going on there with network file access between the two systems that just doesn't jive. Whether the issue is limited to file shares on just the Infrant system or is more general is something probably worth looking into.
I'm guessing it has something to do with the NV, unless of course others using other NAS devices are experiencing similar performance issues under Windows.

egd
2007-02-25, 06:22
Is it faster if you run a PC with Linux and connect that to the NAS ?

Or are you just saying that SlimServer locally installed on the NAS itself is faster ?

In both Windows ans Linux I had/had Slimserver running on a PC. The ReadyNAS NV would die a horrible death if I installed slimserver to the nas and told it to scan ~50k files. I don't have enough faith in the NV to even contemplate that prior to having a complete backup of the NAS.

egd
2007-02-25, 06:25
My setup on Windows 2003 R2 doesn't cause any problems or performance issues. It is wired from W2K3 server to QNAP NAS storage and SB3. A complete rescan of my 5,000 tracks is fine. Any issues with NIC settings on network speed and duplex? It is standard practice to always force this rather than leave it at auto/auto

My setup is wired, linked through a gigabit switch, pc, switch and nv have jumbo frames enabled and set to 9014. Network connects at gigabit so it doesn't look like there are any connection speed issues. Same connection via a Linux box and a rescan puts the NAS under the pump, whereas under a windows rescan you'd hardly know it was happening.

Paul_B
2007-02-25, 09:37
I'll do a rescan tonight (need to anyway to clear things up) and will time the results to compare.

MrSinatra
2007-02-25, 12:04
i'm just curious...

but can't SS run on the NAS? or is it limited to just a select few NAS boxes?

wouldn't it be neat if you had an all in one box solution, (ie, ss, nas, sb = one box) and had a color remote to see what you were doing?

the only drawback there i think would be in routing the audio from your stereo to the box in another room, if you thought it necessary. fiber could do it though.

anyway, i'm just wondering why you aren't running SS on the nas. -mdw

tommypeters
2007-02-25, 13:55
How about what he wrote - "The ReadyNAS NV would die a horrible death if I installed slimserver to the nas and told it to scan ~50k files. "...?

MrSinatra
2007-02-25, 14:07
i guess i just wanted that fleshed out a bit...

other people seem to have gotten their NAS to do it, altho i'm not sure it was that many files...

my Q is, why can't his NAS do it? is it the hardware or the software?

just expound the reasoning a bit... i am thinking about a NAS setup for myself, so this would be good to know.

egd
2007-02-25, 14:45
anyway, i'm just wondering why you aren't running SS on the nas. -mdw

I add albums and edit tag/artwork etc. regularly enough to make a rescanning a regular necessity. With that many files in my library, running a rescan on the NV is not feasible.

MrSinatra
2007-02-25, 14:47
how long would it take?

and wouldn't daily, automated, overnight [re]scanning do the trick?

again, i'm just curious.

egd
2007-02-27, 05:14
how long would it take?

and wouldn't daily, automated, overnight [re]scanning do the trick?

again, i'm just curious.

Not sure, to be honest, but based on a brief experiment I did a while ago my guess is >= a day. My other big fear is that I get a repeat of the box falling over and becoming unresponsive, necessitating a hard reset/power down and resulting in either corrupted data and/or a very, very lengthy rebuild process.

Basically, IMHO I think home/SOHO NAS solutions are currently a joke and cannot be relied upon for reliably storing data.

aubuti
2007-02-27, 08:38
Basically, IMHO I think home/SOHO NAS solutions are currently a joke and cannot be relied upon for reliably storing data.
While something is definitely not right with your present arrangement, imho condemning all home/SOHO NASs is a huge overstatement. My experience (with Buffalo LinkStation HG, definitely at the low end of the NAS market) and that of many others has shown that these little NASs do a good job at their intended purpose: providing network storage for small networks. And they are as reliable as other hard disks, which means that yes, they will die some day.

Just from reading other posts, it seems that a lot of the performance and other problems come along with the more "advanced home" NASs that have RAID and such. Because users paid more, expectations are higher, and RAID makes things considerably more complicated. I've yet to understand the fad for RAID in most home settings -- how critical is it that home users not suffer any down time in the inevitable-though-rare event of a disk crash? Granted, office situations are a different story.

SteveEast
2007-02-27, 08:39
I see very slow scanning with my music on a different NAS device - a Buffalo Terastation. Windows XPSP2. Fortunately I only have a few thousand songs.

Steve.

jonheal
2007-02-27, 10:24
I have really slow scanning on my 2.0 GHz XP system. My library is on a NAS controlled by a Linksys NSLU2.

I always chaalked it up to either slow file performance on the part of the NSLU2 or a lame implementation of SMB on the part of Windows.

Aren't most/all of the NAS devices people on these forums running one flavor of embedded Linux, or another. In which case, they'd all be using SMB from Windows, and experiencing the same issues/problems.

Paul_B
2007-02-27, 15:36
I wonder if it is possible to turn up debugging on the scanning process or run scanner.exe in a verbose mode to see what is going on?

mherger
2007-02-28, 00:42
> I wonder if it is possible to turn up debugging on the scanning process
> or run scanner.exe in a verbose mode to see what is going on?

Run scanner.exe -h to get a list of available parameters. Try "-d_info
-d_scan" for a start.

--

Michael

-----------------------------------------------------------------
http://www.herger.net/SlimCD - your SlimServer on a CD
http://www.herger.net/slim - AlbumReview, Biography, MusicInfoSCR

JJZolx
2007-02-28, 02:39
Aren't most/all of the NAS devices people on these forums running one flavor of embedded Linux, or another. In which case, they'd all be using SMB from Windows, and experiencing the same issues/problems.

Yes. Probably a valid observation, but I wouldn't chalk it up quite yet to Windows. It could also be attributable to either ActiveState Perl, or SlimServer's implementation under Windows.

mherger
2007-02-28, 03:10
> It could also be attributable to either ActiveState
> Perl, or SlimServer's implementation under Windows.

Accessing files on a network share _is_ slower than locally (unless you
have high-end storage). And the NSLU isn't known as one of the better
performing devices on the market. This has nothing to do with neither perl
nor SlimServer.

--

Michael

-----------------------------------------------------------------
http://www.herger.net/SlimCD - your SlimServer on a CD
http://www.herger.net/slim - AlbumReview, Biography, MusicInfoSCR

mherger
2007-02-28, 03:13
I always chaalked it up to either slow file performance on the part of the NSLU2 or a lame implementation of SMB on the part of Windows.

I'm pretty sure this is actually the case. IMHO the NSLU has a throughput of a few (well below 10) megabytes per second whereas todays harddisks easily transfer 40-50MB/s. It's generally an anlucky combination, leaving the data files on a network share while running the application on a distant machine. This has little to do neither with Windows nor Samba (the SMB server used on Linux) but is just due to the NAS' limited CPU power.

Ramage
2007-02-28, 04:12
I've measured the NSLU transferring (download) at about 5MBytes/sec, ie 40Mbits/sec. This is not unreasonable on 100Mbits/s ethernet network.

mherger
2007-02-28, 04:22
> I've measured the NSLU transferring (download) at about 5MBytes/sec, ie
> 40Mbits/sec. This is not unreasonable on 100Mbits/s ethernet network.

That's around my guess. But compared to local access on harddisk this
still is slow. Consider SlimServer fetching every single file of your x00
gigabyte collection: whether the transfer speed is 5MB or as 50MB makes a
huge difference.

--

Michael

-----------------------------------------------------------------
http://www.herger.net/SlimCD - your SlimServer on a CD
http://www.herger.net/slim - AlbumReview, Biography, MusicInfoSCR

bpa
2007-02-28, 05:15
The OP in post #1 said


I have a large FLAC library (~50k songs) but damnit, it shouldn't take hours to scan just because it is located on a NAS, especially not when the same library scans in under 20 minutes under Linux.

It is not clear whether the Linux case is using local or NAS located files. If the library is on a NAS in both cases and the only difference is slimserver is running on Windows vs Linux - then it looks like an Windows network or Windows/Perl issues and not the speed of the NAS.

jonheal
2007-02-28, 07:02
The OP in post #1 said

It is not clear whether the Linux case is using local or NAS located files. If the library is on a NAS in both cases and the only difference is slimserver is running on Windows vs Linux - then it looks like an Windows network or Windows/Perl issues and not the speed of the NAS.

5mps vs. 40mbs. A factor of nearly 10. The OP's observation of a 20 minute local scan multiplied by a factor of 10 would result in a scan of 3 1/2 hours.

50,000 tracks. That's probably more 500GBs of data to sift through.

SteveEast
2007-02-28, 08:48
Reading some of the OP's other posts reveals that the Linux timings are indeed using the NAS library. So the difference in performance between Linux and Windows with the same NAS is indeed dramatic.

Steve.

snarlydwarf
2007-02-28, 10:02
Reading some of the OP's other posts reveals that the Linux timings are indeed using the NAS library. So the difference in performance between Linux and Windows with the same NAS is indeed dramatic.

Are both systems accessing via SMB? Many NAS boxes support NFS... It may be that NFS provides faster access. (Which wouldnt surprise me at all, less 'abstraction' going on, though the difference is huge and that wouldnt explain it all unless SMB is really really dumb and left out something as crucial as random access to files... "please read the last 4k of the file to look for a tag" is a lot faster than "please grab the whole file so I can find the tag...")

Now I am curious as to what operations SMB supports.

JJZolx
2007-02-28, 10:36
This has little to do neither with Windows nor Samba (the SMB server used on Linux) but is just due to the NAS' limited CPU power.

A simple test would be: Run a SlimServer scan on a Windows machine accessing files on the NAS. Then run it on Linux system accessing the same files across the network on the NAS. If the scan on Linux system runs considerably faster, then there's something wrong other than just the limited throughput of the NAS itself.

The OP claimed (maybe in the other thread) that this was exactly the case. I haven't had the opportunity to test it, but I have seen how slow a scan is going from my Windows server to a library stored on an Infrant NAS.

jonheal
2007-02-28, 10:36
Are both systems accessing via SMB? Many NAS boxes support NFS... It may be that NFS provides faster access. (Which wouldnt surprise me at all, less 'abstraction' going on, though the difference is huge and that wouldnt explain it all unless SMB is really really dumb and left out something as crucial as random access to files... "please read the last 4k of the file to look for a tag" is a lot faster than "please grab the whole file so I can find the tag...")

Now I am curious as to what operations SMB supports.

Can you actually do that, only open/read a portion of a file? I'm just a "sorta" programmer, but I am only aware of methods of opening an entire file at once.

snarlydwarf
2007-02-28, 10:39
Can you actually do that, only open/read a portion of a file? I'm just a "sorta" programmer, but I am only aware of methods of opening an entire file at once.

Well you open the whole file, but use lseek/fseek/whatever to seek to the part you want.

Thats why id3 tags are at either the beginning or end of the file: it saves a ton of processing if you can ignore most of the file.

(There are two schools of thought on whether the beginning or end is better... beginning is great for fixed-length data, since it can be found so easily... but if it "grows" you have to move everything after it... so most beginning-tag-writers use padding to keep some room for changes. End doesnt have that problem, but finding the tag backwards is harder.)

jonheal
2007-02-28, 10:42
A simple test would be: Run a SlimServer scan on a Windows machine accessing files on the NAS. Then run it on Linux system accessing the same files across the network on the NAS. If the scan on Linux system runs considerably faster, then there's something wrong other than just the limited throughput of the NAS itself.

The OP claimed (maybe in the other thread) that this was exactly the case. I haven't had the opportunity to test it, but I have seen how slow a scan is going from my Windows server to a library stored on an Infrant NAS.

Plus, 100mps ethernet itself is going to limit data transfers to 6-10MB/s, far slower than your EIDE or SATA bus.

I think it takes nearly an hour to scan my ~6000 tracks.

snarlydwarf
2007-02-28, 10:43
Ah found the SMB protocol specs:


SMB_COM_READ Client supplies TID, FID, file offset, and number of bytes to read. Successful server response includes the requested file data.

That should allow random seeks, though there is still some abstraction between things.

Windows probably doesnt have a decent profiler unless you have Visual Studio... too bad, it would be interesting to see where the cpu is spending the time.

SteveEast
2007-02-28, 10:43
Are both systems accessing via SMB? Many NAS boxes support NFS... It may be that NFS provides faster access.

The Infrant ReadyNAS NV does support NFS. It would be interesting to install an NFS client on the Windows box and see if that made a difference.

Steve.

jonheal
2007-02-28, 10:47
Well you open the whole file, but use lseek/fseek/whatever to seek to the part you want.

Thats why id3 tags are at either the beginning or end of the file: it saves a ton of processing if you can ignore most of the file.

(There are two schools of thought on whether the beginning or end is better... beginning is great for fixed-length data, since it can be found so easily... but if it "grows" you have to move everything after it... so most beginning-tag-writers use padding to keep some room for changes. End doesnt have that problem, but finding the tag backwards is harder.)

Then if you have to open to whole file, you have to bring the whole file over the network to load into memory. Using 10MB per file as an example, it would take my NSLU2 85 minutes to send the files to the PC for Slimserver to process -- which is more or less the time it takes for a scan on my system.

aubuti
2007-02-28, 10:51
A simple test would be: Run a SlimServer scan on a Windows machine accessing files on the NAS. Then run it on Linux system accessing the same files across the network on the NAS. If the scan on Linux system runs considerably faster, then there's something wrong other than just the limited throughput of the NAS itself.

The OP claimed (maybe in the other thread) that this was exactly the case. I haven't had the opportunity to test it, but I have seen how slow a scan is going from my Windows server to a library stored on an Infrant NAS.

Just yesterday I realized that my dual boot (Win2K / Ubuntu) box accessing my music library on a NAS is perfect for just such a test. But if I confirm a big difference in scanning times between Linux and Windows, doesn't that still leave two possible explanations (at least): bad implementation of SMB on Windows and/or something peculiar to slimserver on Windows?

Anyway, I'll give it a shot sometime in the next few days and report back. As well as a report on the scan time when the NAS runs slimserver and is therefore accessing a local disk.

jonheal
2007-02-28, 11:14
Just yesterday I realized that my dual boot (Win2K / Ubuntu) box accessing my music library on a NAS is perfect for just such a test. But if I confirm a big difference in scanning times between Linux and Windows, doesn't that still leave two possible explanations (at least): bad implementation of SMB on Windows and/or something peculiar to slimserver on Windows?

Anyway, I'll give it a shot sometime in the next few days and report back. As well as a report on the scan time when the NAS runs slimserver and is therefore accessing a local disk.

My money is on similar times for both OSs.

snarlydwarf
2007-02-28, 11:17
Then if you have to open to whole file, you have to bring the whole file over the network to load into memory. Using 10MB per file as an example, it would take my NSLU2 85 minutes to send the files to the PC for Slimserver to process -- which is more or less the time it takes for a scan on my system.

"open" doesn't mean "copy".

It just means "find this file and return a 'handle' to it for later operations".

Opening a file should take very little time (unless you have something like a large directory where it can take time for the OS to find the file in the directory), since it just finds the file, checks permissions and performs no other operations (well maybe updating the 'access time' of the file, but that is effectively in the directory or inode not the file itself).

Somewhere deep in the OS, there is a table of open files.. the "handle" points to an item in this table.

It is somewhat similar with network operations... the handle is just abstracted another layer.

Yeah, the timing -really- sounds like it is reading the whole file. It seems that it shouldnt have to do that from the SMB docs. I know it doesn't have to do that at all with NFS. (NFS isn't perfect by any means.. but random access to files is completely transparent.)

jonheal
2007-02-28, 11:33
"open" doesn't mean "copy".

It just means "find this file and return a 'handle' to it for later operations".

Opening a file should take very little time (unless you have something like a large directory where it can take time for the OS to find the file in the directory), since it just finds the file, checks permissions and performs no other operations (well maybe updating the 'access time' of the file, but that is effectively in the directory or inode not the file itself).

Somewhere deep in the OS, there is a table of open files.. the "handle" points to an item in this table.

It is somewhat similar with network operations... the handle is just abstracted another layer.

Yeah, the timing -really- sounds like it is reading the whole file. It seems that it shouldnt have to do that from the SMB docs. I know it doesn't have to do that at all with NFS. (NFS isn't perfect by any means.. but random access to files is completely transparent.)

I can see how it might be possible for the OS to query the volume directory about a file, and then get a response, "Yes, we have that file. This portion of it is on sector X of the hard drive, and that portion of it is on sector Y ...," etc. And then with some intelligence, SlimServer looks into the first and last portions of the file that the directory points to for tag information.

But, if the OS must open the file, then it would need to read all of the file's bytes and load them into memory -- and bring them across the network to do so.

If you select a file's properties in Windows, you see name, last modifed, size, etc. and regardless of selecting a big or small file, that dialog appears instantly. My guess is that this information is not coming from the file in real time, but was added to the disk's directory when the file was last modified.

To me, the SMB_COM_READ command looks like it is reading a portion of a file already in memory. There's nothing in the parameters about disk sectors.

snarlydwarf
2007-02-28, 11:55
I can see how it might be possible for the OS to query the volume directory about a file, and then get a response, "Yes, we have that file. This portion of it is on sector X of the hard drive, and that portion of it is on sector Y ...," etc. And then with some intelligence, SlimServer looks into the first and last portions of the file that the directory points to for tag information.

The application has no idea what sectors the file occupies, nor does it care. That is the OS's problem. The OS just says, "Okay, found it, you have permissions to read it as you asked, and next time you want to do something tell me you want to fondle file-handle-5 for your process"

The application program calls read( 5, buffer, length)... the OS looks up the '5' in its table for the process, finds the file handle, figures out what the current read-pointer is, figures out what blocks are needed to be read in if any (it may be in buffers), and does so, copying length bytes to the buffer, and returning.



But, if the OS must open the file, then it would need to read all of the files bytes and load them into memory -- and bring them across the network to do so.

No, it wouldn't.


If you select a file's properties in Windows, you see name, last modifed, size, etc. and regardless of selecting a big or small file, that dialog appears instantly. My guess is that this information is not coming from the file in real time, but was added to the disk's directory when the file was last modified.

That isnt coming from the file at all: it is coming from the directory. The directory points to the file and has all the information about it. (Or something, I haven't seriously played with Windows file systems).

On Unix it is a bit more obtuse: the directory contains a list of filenames, and inode numbers... the inode numbers contain all the information about a file (permissions, ownership, blocks used, etc), but same basic concept. Just the real details about a file arent in the directory itself. (This is, btw, how "hard links" work on Unix ... two directory entries pointing to the same inode, which points to the same file.)


To me, the SMB_COM_READ command looks like it is reading a portion of a file already in memory. There's nothing in the parameters about disk sectors.

No, it reads it from the disk.

Modern OS's don't need to read stuff into memory on open. Even CP/M-80 didn't.

Paul_B
2007-02-28, 13:49
Just had a though on this subject. Is Windows woeful because of anti-virus software? My setup is fast and has no performance issues. However, I don't run AV software on my server because I am very careful about what is installed and don't surf the Net. AV software causes no end of problems as it interferes with normal operations.

Paul_B
2007-02-28, 14:46
I have run the following command against my collection of 5,000 songs:

scanner --wipe --cleanup --d_info --d_server --d_scan \\ip-address\public\music

The rescan took just over 30 minutes with the additional debugging. One thing I did notice whilst using Perfmon is the disk queue goes high every few seconds. Now I know nothing about MySQL but I do know something about Exchange servers and both are transaction based databases. The MySQL instance seems to use circular logging with just two log files. It must surely mean flushing the logs to the database, closing and opening files fairly frequently which is an expensive operation on performance. My disk queue was modal at < 1 but regualarly spiked above 20 (MS state a disk queue > 4 per spindle indicates a problem)

egd
2007-03-01, 06:38
The OP in post #1 said

It is not clear whether the Linux case is using local or NAS located files. If the library is on a NAS in both cases and the only difference is slimserver is running on Windows vs Linux - then it looks like an Windows network or Windows/Perl issues and not the speed of the NAS.

To clarify for everyone, I am referring to the same ReadyNAS NV and library connected via the same switch, cables IP addresses etc. Running the scan from from Windows yields a very significantly slower outcome compared with the same scan running the same PC under Linux.

egd
2007-03-01, 06:42
The Infrant ReadyNAS NV does support NFS. It would be interesting to install an NFS client on the Windows box and see if that made a difference.

Steve.

If you know of one I'm happy to run this experiment

SteveEast
2007-03-01, 08:21
If you know of one I'm happy to run this experiment

Microsoft seems to have one as part of Microsoft Windows Services for UNIX 3.5.

http://www.microsoft.com/technet/interopmigration/unix/sfu/sfu35int.mspx

Looks like you can download it (200+ MB) from:

http://www.microsoft.com/downloads/details.aspx?FamilyID=896C9688-601B-44F1-81A4-02878FF11778&displaylang=en

Steve.

jonheal
2007-03-01, 08:40
To clarify for everyone, I am referring to the same ReadyNAS NV and library connected via the same switch, cables IP addresses etc. Running the scan from from Windows yields a very significantly slower outcome compared with the same scan running the same PC under Linux.

So you've got a dual-boot PC (Windows/Linux)?

egd
2007-03-01, 13:01
So you've got a dual-boot PC (Windows/Linux)?

No, but I have run w2k3 and Ubuntu on the box on various occasions - enough times to know that the performance difference was not a random anomaly. I also have a 2nd box that I've tested in the same way and achieved the same outcome. Not that hard to do because I have in the past had Linux and Windows SOEs for both PCs so the time requirement was minimal.

The difference in scan speed under Linux versus Windows is so vast it is even audible. Under Linux you can hear the ReadyNAS drives are processing a lot of data almost from the second you hit the rescan button. Doing the same under Windows never puts the ReadyNAS under the same "pressure", in fact there is barely a discernible audible difference under Windows between the ReadyNAS being idle and performing a rescan. If it wasn't for the blinking of the ReadyNAS HDD activity LED you'd think it was standing idle.

egd
2007-03-01, 13:06
Microsoft seems to have one as part of Microsoft Windows Services for UNIX 3.5.

Will attempt it over the weekend. Not sure you can force the ReadyNAS to use NFS under Windows as it defaults to CIFS under Windows and from memory CIFS cannot be disabled on the NV but I'll look into it.

JJZolx
2007-03-01, 13:12
in fact there is no discernible audible difference under Windows between the ReadyNAS being idle and performing a rescan. If it wasn't for the blinking of the ReadyNAS HDD activity LED you'd think it was standing idle.

That's pretty much the same thing I saw. There's an initial phase of a scan where SlimServer just gathers up a list of all the audio files on the server (in SlimServer 7.0 it uses a count of these files to create a progress bar during the 'real' scanning work of reading tags and finding byte offsets). That phase was taking over 8 minutes just to gather the file list for 12,000 files, during which there was very little disk activity on the Infrant NAS. When the real scanning began, disk activity increased considerably. On the same Windows server with the files on an internal drive, the initial phase takes maybe 20 seconds.

jonheal
2007-03-01, 13:21
No, but I have run w2k3 and Ubuntu on the box on various occasions - enough times to know that the performance difference was not a random anomaly. I also have a 2nd box that I've tested in the same way and achieved the same outcome. Not that hard to do because I have in the past had Linux and Windows SOEs for both PCs so the time requirement was minimal.

The difference in scan speed under Linux versus Windows is so vast it is even audible. Under Linux you can hear the ReadyNAS drives are processing a lot of data almost from the second you hit the rescan button. Doing the same under Windows never puts the ReadyNAS under the same "pressure", in fact there is barely a discernible audible difference under Windows between the ReadyNAS being idle and performing a rescan. If it wasn't for the blinking of the ReadyNAS HDD activity LED you'd think it was standing idle.
When I run a scan (from the Windows XP PC), the disk attached to the NSLU2 churns constantly until the scan has completed.

aubuti
2007-03-02, 11:58
I have run the following command against my collection of 5,000 songs:

scanner --wipe --cleanup --d_info --d_server --d_scan \\ip-address\public\music
I've used a similar approach along with the linux `time' command to record scanning times under linux. Is there a DOS/Win equivalent to `time'? And no, I don't mean the DOS command that tells you what time it is, but one that tells you how long it takes to execute a given command. Thanks.

jonheal
2007-03-02, 12:10
I've used a similar approach along with the linux `time' command to record scanning times under linux. Is there a DOS/Win equivalent to `time'? And no, I don't mean the DOS command that tells you what time it is, but one that tells you how long it takes to execute a given command. Thanks.

I guess you could get the system time before and after running the scan from a batch file.
time /T >>C:\results.txt
scanner --wipe --cleanup --d_info --d_server --d_scan \\ip-address\public\music
time /T >>C:\results.txt

Paul_B
2007-03-02, 12:15
Two options is run a from a batch file and echo time before and after.

If you aren't echoing anything to screen then you can change the command prompt with:

prompt $T $P$G

aubuti
2007-03-02, 13:56
My money is on similar times for both OSs.
Certainly not if count how long it took me to figure out how to get slimserver on Windows read the library on my NAS!! But if you don't count that, Win2K was about 40% slower to scan than Ubuntu.

Server hardware: Dell P3 500MHz with 256MB RAM,
NAS hardware: Buffalo LinkStation HD-HG250LAN
Network: 100Mbs ethernet through a Netgear WGR614v3 router
Slimserver: Slimserver 6.5.1 (official release)
Library: 298 albums | 3848 songs | 228 artists (mostly FLAC)

The Dell is a low horsepower machine, but in neither case did it have to start swapping to virtual memory. In each case there was nothing else major running on the machine while it was scanning. Scanning times are....

Windows 2000/SP4: 17:53 (mm:ss)
(command: scanner --wipe --d_server --priority=0 M:\

Ubuntu 6.06: 12:48
(command: time /usr/bin/perl /usr/local/slimserver/scanner.pl --prefsfile=/etc/slimserver.pref --priority=0 --wipe --d_server)

And for comparison, running on the LinkStation itself (running Debian, 128MB RAM and 266MHz PPC): 36:03

JJZolx
2007-03-02, 14:08
I've used a similar approach along with the linux `time' command to record scanning times under linux. Is there a DOS/Win equivalent to `time'? And no, I don't mean the DOS command that tells you what time it is, but one that tells you how long it takes to execute a given command. Thanks.

Run the scan from a batch file. You could use this to get the elapsed time:



@echo off & setlocal enableextensions
call :getTime StartTime
******* do your thing here *******
call :getTime StopTime
call :elapsedTime %StartTime% %StopTime% ElapsedTime
call :formatTime %ElapsedTime% Elapsed
echo Elapsed Time (hh:mm:ss): %Elapsed%
goto :eof

:: Return current time in 100ths of seconds
:getTime
for /f "tokens=1-4 delims=:.," %%T in ("%time%") do (
set /a %1=%%T*360000+%%U*6000+%%V*100+%%W
)
goto :eof

:: Calculate the difference between two times
:elapsedTime
:: account for passing midnight
if %2 lss %1 set /a %2+=8640000
set /a %3=%2-%1
goto :eof

:: Format a time period into hours:minutes:seconds.hundredths
:formatTime
setlocal enableextensions
set /a hr=(%1)/360000
set /a mn=(%1-360000*%hr%)/6000
set /a sc=(%1-360000*%hr%-6000*%mn%)/100
set /a hu=%1-360000*%hr%-6000*%mn%-%sc%*100
set hr=0%hr%
set mn=0%mn%
set sc=0%sc%
set hu=0%hu%
endlocal&set %2=%hr:~-2%:%mn:~-2%:%sc:~-2%.%hu:~-2%
goto :eof

bpa
2007-03-02, 14:31
It would be interesting to run netstat before and after a scan to get TCP statistics to see if there is any significant difference in the volume and/or type of network traffic between a Linux scan and a Windows scan.

Triode
2007-03-02, 14:46
Doesn't running the scanner with --progress give you timing info for dos and windows?

jonheal
2007-03-02, 14:59
Certainly not if count how long it took me to figure out how to get slimserver on Windows read the library on my NAS!! But if you don't count that, Win2K was about 40% slower to scan than Ubuntu.

Server hardware: Dell P3 500MHz with 256MB RAM,
NAS hardware: Buffalo LinkStation HD-HG250LAN
Network: 100Mbs ethernet through a Netgear WGR614v3 router
Slimserver: Slimserver 6.5.1 (official release)
Library: 298 albums | 3848 songs | 228 artists (mostly FLAC)

The Dell is a low horsepower machine, but in neither case did it have to start swapping to virtual memory. In each case there was nothing else major running on the machine while it was scanning. Scanning times are....

Windows 2000/SP4: 17:53 (mm:ss)
(command: scanner --wipe --d_server --priority=0 M:\

Ubuntu 6.06: 12:48
(command: time /usr/bin/perl /usr/local/slimserver/scanner.pl --prefsfile=/etc/slimserver.pref --priority=0 --wipe --d_server)

And for comparison, running on the LinkStation itself (running Debian, 128MB RAM and 266MHz PPC): 36:03

I guess I would expect it to be a little slower on windows since it's dealing with a non-native file system. It would be interesting to see if the difference is linear with larger collections.

aubuti
2007-03-02, 15:11
Thanks for the timing tips under DOS. I was wondering if there was something better than the [time / scan / time] batch file kludge, but for these purposes that's good enough. Actually, the times I reported above are the differences between the first and last lines that scanner reports with --d_server, e.g.,

2007-03-02 12:03:08.4935 SlimServer OSDetect init...
2007-03-02 12:15:56.3895 SlimServer scanner cleaning up.

FWIW, Ubuntu's `time' command reported that as 12m51.089s for 'real' time, so reading off the debug output only cuts a few seconds from the truth.

aubuti
2007-03-02, 15:16
I guess I would expect it to be a little slower on windows since it's dealing with a non-native file system. It would be interesting to see if the difference is linear with larger collections.
The NAS is mounted on the Ubuntu system using smbfs, so there's still a translation layer going on there. And I agree that it would be interesting to if the difference is larger or smaller with bigger collections.

Paul_B
2007-03-03, 01:49
The other issue on speed is how MySQL is configured on Linux and Windows. I guess at that point you may want to look at a single album and see if it really is the NAS or some other component.

A direct file copy under the two OS may also give an indicative result of OS perfromance.

aubuti
2007-03-03, 07:30
Those are all fine suggestions about running netstat before and after, MySQL configuration, and timing direct file copies. But someone else is going to have to answer them. Sorry, but as I usually run slimserver on my NAS (and occasionally under Ubuntu), the Linux/Windows scanning questions just don't have enough personal interest for me to spend more time re-booting, timing, etc. Especially because doing the Windows bit means sitting at the server itself, which is in a cramped space in the basement.

Now, if someone wanted to give me 10k - 40k new tracks (legally and compatible with my musical tastes, of course) I'd be happy to test whether the difference in scanning times is linear ;o)

Gplouffe
2008-04-03, 20:16
Not certain if anything concrete came out of this discussion but I recently took a 1.6mhz 500mb ram desktop and went from linux (debian) to windows xp sp2. Under linux, performance was great. Note: Music is located on a Buffalo Terastation NAS >50K songs. Went to XP because of another server need that I could not statisfy with Linux :( and performance now is poor when searching library, especially when searching through "music folder".

Web performance has also decreased.

I tried the sql setting changes and did not notice any benefit. My gut tells me it is IO related.

Any definitive answers on this?

Thanks

GP

Listener
2008-04-03, 21:46
Then if you have to open to whole file, you have to bring the whole file over the network to load into memory. Using 10MB per file as an example, it would take my NSLU2 85 minutes to send the files to the PC for Slimserver to process -- which is more or less the time it takes for a scan on my system.

Opening a file does not automatically read it. You clearly don't understand how file I/O works.

Bill

ceejay
2008-04-03, 23:20
Not certain if anything concrete came out of this discussion but I recently took a 1.6mhz 500mb ram desktop and went from linux (debian) to windows xp sp2. Under linux, performance was great. Note: Music is located on a Buffalo Terastation NAS >50K songs. Went to XP because of another server need that I could not statisfy with Linux :( and performance now is poor when searching library, especially when searching through "music folder".

Web performance has also decreased.

I tried the sql setting changes and did not notice any benefit. My gut tells me it is IO related.

Any definitive answers on this?

Thanks

GP

No definitive answer, but I wonder if in moving from Linux to Windows you have changed the file sharing protocol, eg NFS to Samba? That would make a difference, I guess.

pippin
2008-04-04, 02:33
I tried the sql setting changes and did not notice any benefit. My gut tells me it is IO related.

Any definitive answers on this?


No definitive answers, but MY gut tells me it's poor scheduling on windows. The overall performance is MUCH worse on Windows, especially if you work on the PC you use as a server.

But this is the same for other server apps like Apache, MySQL, etc.

jaffacake
2008-04-04, 02:46
Not certain if anything concrete came out of this discussion but I recently took a 1.6mhz 500mb ram desktop and went from linux (debian) to windows xp sp2. Under linux, performance was great. Note: Music is located on a Buffalo Terastation NAS >50K songs. Went to XP because of another server need that I could not statisfy with Linux :( and performance now is poor when searching library, especially when searching through "music folder".

Web performance has also decreased.


People often, rightfully, feel the need to run anti-virus and firewalls within a Windows environment. These can seriously reduce IO performance.

Are you using either of these?

Additionally, it's likely that with just '500MB' of RAM that you are paging excessively in Windows...the Linux base would likely use less RAM. For such an old machine, another 512MB of RAM is likely to cost peanuts and may make all the difference.

egd
2008-04-04, 03:34
Seeing this thread resurface reminded me I was going to run tests under SC7 and screendump the results here. The Windows based scan of the same NAS-based library (limited to the 0-E tree) is running as I type this. If someone can tell me how to embed inline links to the full sized images in a forum post I'll post the results as soon as W2K3 has finished its thing.

My test has comprised the following:
1 x Ubuntu 7.10/32-bit box running a quad core cpu (q6600), SqueezeCenter Version: 7.1 - 18337
1 x Windows Server 2003/32-bit box running same spec quad core cpu (q6600), SqueezeCenter Version: 7.0.1 - 18351
both of the above networked via SMCGS5 gigabit unmanaged switch, everything cabled with cat5e
music located on Thecus N5200PRO NAS

both of the abovementioned previously had my entire NAS library scanned. Doing a clear and rescan results in significant local disk activity prior to initiating scan, so I made sure both started on a level playing field by setting the library folder to point at a single album, let it update, and then carried out a clear library and rescan everything whilst still pointing at the single album. When that had completed I then set the library folder to point to the 0-E portion of my library and again ran a clear library and rescan everything. The screendumps that I will post show the results.

mherger
2008-04-04, 04:31
> Windows results:
> [image: http://www.members.iinet.net.au/~egd/C&RTimings_W2K3_0-E.png]
>
> Linux results:
> [image:
> http://www.members.iinet.net.au/~egd/C&RTimings_Ubuntu_0-E.png]

Are both using SMB? Do you have numbers scanning the same collection on the Thecus itself?

--

Michael

egd
2008-04-04, 04:51
I'm really surprised at how big the differences in scan times are. Cannot explain the differences in library stats given they're pointing to the same folder. Both Windows and Linux report 21,209 FLAC files in 0-E and its child directories.


Are both using SMB?The Linux box has mounted the NAS share using NFS, I presume the Windows box is using CIFS? I'm not sure that this is where the performance differences lie because I've observed the same performance characteristics with locally stored libraries.


Do you have numbers scanning the same collection on the Thecus itself?Not at the moment. To get that I have to kill my library and then rebuild it. I may do that later tonight and let it rebuild while I sleep. Are the NAS' own timings relevant?

funkstar
2008-04-04, 05:50
Not at the moment. To get that I have to kill my library and then rebuild it. I may do that later tonight and let it rebuild while I sleep. Are the NAS' own timings relevant?
Should be in the reagion of 25minutes for a full scan on a N5200Pro. My lat scan was about 22min for ~18,000 tracks.

mherger
2008-04-04, 06:03
>> Are both using SMB?The Linux box has mounted the NAS share using NFS, I
> presume the Windows box is using CIFS?

Ok, NFS is known to be quit a bit faster than SMB/CIFS.

> rebuild it. I may do that later tonight and let it rebuild while I
> sleep. Are the NAS' own timings relevant?

I'd be interested to see how it compares to your other systems (and mine ;-)). I'd expect it to pretty fast too, as the slow network transfer doesn't apply.

--

Michael

egd
2008-04-04, 06:08
I ran a clear and rescan on my NAS a few days ago (but without first pointing the library to a single album and rescanning) and screendumped the full library time http://www.members.iinet.net.au/~egd/N5200PROLibraryScan.jpg. Those stats are 86,352 tracks in 110.63 minutes, meaning a 0-E scan will take roughly 27.17 minutes. If I follow the same approach that I followed testing SC on the PC's I should shave at least a few minutes off that time, so Funkstar's estimate is likely on the money. That'd make the NAS a full 20 minutes faster than the Windows box.

Michael, the above approximations suffice or would you prefer actuals?

mherger
2008-04-04, 06:45
> Michael, the above approximations suffice or would you prefer actuals?

That's ok. Thanks!

--

Michael

Sona
2008-04-04, 15:57
My dinosaur PC is currently in its fifth hour doing a scan of a local USB drive. I know much of this discussion concerns NAS drives, but hopefully this is appropriate here.

Otherwise, I'll open up a new thread and whine some more...

My computer crashed last week so I have had to reinstall everything and I have just installed SC for the first time. I was running SS previously, though the scammer has always been a resource hog. My poor CPU is maxed out at 100% usage, and my firewall,Zonealarm,gives the appearance that scanning the local drive somehow involves the internet.

IT SHOULD NOT NEED TO IMHO.

I'm much less in the know about programming than many of you, but I caught the reference about firewalls slowing the IO rate way down, but this is simply assinine.

Yes, I'm still using a 2001 Gateway desktop, with some dead standard kind of RAM that has been crazy expensive to upgrade (another rant)

BUT, really people, examining a file structure is a simple basic operation, not some resource hog PC Game for which one would need some $3K Alienware invincible box.

What gives? What possible reason could make this so slow and yes I believe poorly implemented.

In more positive news, the scan is up to 20755 of 22273 so the end is surely in sight.

Thank God. I still have more programs to download and reinstall and this process seems to slow up my superfast BB access as well, if only bc with the CPU so occupied the browser can barely get a word in edgewise.

Gplouffe
2008-04-04, 17:30
No definitive answer, but I wonder if in moving from Linux to Windows you have changed the file sharing protocol, eg NFS to Samba? That would make a difference, I guess.

Under windows I was using a windows share (SMB I believe??) and under Debian I mounted CIFS if that answers your question? The performance difference is so great that I will be moving back to Linux. The effort required to solve the problem is likely greater than the effort to reload Debian. And I just found out that the other mission critical (if there is such a thing for the home) application I needed to run is now going to be released as a native linux app.

Duet is in my future!

radish
2008-04-04, 19:38
I'm much less in the know about programming than many of you, but I caught the reference about firewalls slowing the IO rate way down, but this is simply assinine.

Firewalls slow network access down. Other users on this thread are using NAS units, which are network connected, hence the relevance. In your case, it's probably an old, inefficient USB implementation on your motherboard. It's also probably USB 1 which is horribly slow at the best of times.



BUT, really people, examining a file structure is a simple basic operation, not some resource hog PC Game for which one would need some $3K Alienware invincible box.

Sure, it's simple and basic. Doesn't make it quick.



What gives? What possible reason could make this so slow and yes I believe poorly implemented.

What makes you think it's poorly implemented? Any evidence? Any advice on how it can be made quicker?


this process seems to slow up my superfast BB access as well, if only bc with the CPU so occupied the browser can barely get a word in edgewise.
More evidence that USB is causing the problem. Old USB implementations often take huge amounts of CPU. If you can't make the disc local, buy a $10 USB2 card and that will help.

Sona
2008-04-04, 20:35
In your case, it's probably an old, inefficient USB implementation on your motherboard. It's also probably USB 1 which is horribly slow at the best of times.

More evidence that USB is causing the problem. Old USB implementations often take huge amounts of CPU. If you can't make the disc local, buy a $10 USB2 card and that will help.

USB 2.0, installed a Stratitec USB 2.0 upgrade card, (ICUSB25, I think) long ago. Zero evidence USB is the culprit.


Firewalls slow network access down. Other users on this thread are using NAS units, which are network connected, hence the relevance. In your case, it's probably an old, inefficient USB implementation on your motherboard. It's also probably USB 1 which is horribly slow at the best of times.


Firewalls slow down access? Maybe, maybe not. I did take the step of unplugging the WAN cable from my router and then turning off ZA, AVG, and Spysweeper to see if that would increase the scanning speed. CPU usage in task manager was still clipping at 100%.




Sure, it's simple and basic. Doesn't make it quick.


Um, yes, simple and so basic a function that very little time would be required to perform. Hell, programming files stored on cassette loaded faster to the TI 99/4A. Come on, file management is very low down on computer use primary functions list. File manager or Windows explorer brings it up fast.


If you can't make the disc local, buy a $10 USB2 card and that will help.

The drive IS local, attached to the desktop running SC.


What makes you think it's poorly implemented? Any evidence? Any advice on how it can be made quicker?



Why do I think it's poorly implemented? Because flat out no simple file retrieval and basic database info should require vast amount of resources and time. Also, a casual scan of other thread titles seems to indicate others are facing this issue as well, and not simply with NAS drives. (Which I have seen marketed as capable of running SC alone. My dinosaur PC must at least dust them.)

Suggestions? Maybe let the OS do the file structure and simply access it through SC. For that matter, I am unclear why the scanning needs to occur at all. However, I have scanned music libraries in other media players, say Media Monkey for instance, and it is able to proceed at a much more reasonable clip. WinAmp, WMP, iTunes: all do it faster. Why reinvent the wheel?

Which makes me wonder - not that I really want to do this - that I could load iTunes, use it to scan my lossless library of WAV files, then select the option to have SC monitor iTunes and dispense altogether with using the SC scammer.

Sona
2008-04-04, 21:01
I just discovered the scanner.log file on one of the settings tabs and viewed the contents.

I think I'm going to have to admit to being both wrong and right.

Right in that a directory scan took about 2 seconds (if the stats are to be believed) and wrong in that perhaps there is something I am doing wrong or have wrong with my system.

Still, since the log lists some playlist errors and MPEG Audio Frame Broken/Bitshift errors. Although, to be fair, the error messages are logged with time they occured and they seem to post in relatively quick succession. And after I thought the scan was complete the various artist merges and artwork scans started and seemed to take really long.

Is there a list around to the effect of, before scanning, delete all playlists which are no longer valid and do xy and z to clean up your drive b4 scanning?

The plot thickens.

Thx and goodnight.

gusi
2008-04-05, 10:51
I'll admit to not having read the whole thread. But I have had similar scanning problems when hitting links/shortcuts in windows.

check
http://forums.slimdevices.com/showthread.php?t=39296

Try dir *.lnk /s to find the link, it should be a very quick check.

Good luck and apologies if it has been been mentioned before.

Gus

pski
2008-04-05, 15:36
I've just rebuilt a w2k3 machine and installed SlimServer 6.5.2 - 11509 - Windows Server 2003 - EN - cp1252. Accompanying it is
Perl Version: 5.8.8 MSWin32-x86-multi-thread and MySQL 5.0.22-community-nt

I have a large FLAC library (~50k songs) but damnit, it shouldn't take hours to scan just because it is located on a NAS, especially not when the same library scans in under 20 minutes under Linux. I'm annoyed that I started a scan operation ovr four hours ago, came back to the house after being out for most of the afternoon only to find the damned thing is still scanning - with scanning set to highest priority.

What gives, any ideas?

If you are wired (gigabit,) be sure to use cat6. Cat5 or cat5E generally won't make it. (True, the switch/router DOES make an amazing show, though...)

It may seem obvious, but was the Linux box using the same cable/port? I have at least three switches in the closet with bad ports marked.

I had similar experiences with (lack of) speed when I was first using gigbit between two XP Pro machines. (It just didn't seem to work..)

Also, some switches toss their cookies periodically. I have mine on an appliance timer so they get reset each morning.

pski
2008-04-05, 15:47
While we're on performance, could you telnet to the Thecus and

cat /proc/cpuinfo

?

What kind of bogomips is that puppy doing?

I'm running a Buffalo TS Pro II that's only doin' 498 and my speed is wire-constrained... of course, I don't have any 100mb devices on that segment (or my dlink switch would drop to half-duplex.)

pski

funkstar
2008-04-05, 16:17
Just to add more data to this, I can scan the library on my N5200 with my Windows HTPC over gigabit (and no, it's not Cat6, which is not _required_ for gigabit) is roughly the same amount of time as the SqueezeCenter module on the N5200 itself.

egd
2008-04-06, 13:21
Ok, NFS is known to be quit a bit faster than SMB/CIFS.

I'd be interested to see how it compares to your other systems (and mine ;-)). I'd expect it to pretty fast too, as the slow network transfer doesn't apply. Two things: 1) I presume I can force one Linux box to mount another Linux box using SMB - if so, how do I go about it? Would be interesting to see the results. 2) How does it compare to yours?

egd
2008-04-06, 13:23
(and no, it's not Cat6, which is not _required_ for gigabit)thought this too, but not being a networking engineer I figured I'd stay out of the debate. I don't even have two lots of CAT6 to try the theory, albeit I'm going to be buying two reels for a roll-your-own home wiring as part of a renovation I'm planning.

aubuti
2008-04-06, 17:44
Two things: 1) I presume I can force one Linux box to mount another Linux box using SMB - if so, how do I go about it? Would be interesting to see the results. 2) How does it compare to yours?
Somewhere earlier in this thread (post #57) I reported on such a test. Re mounting another linux filesystem using smbfs, I don't have the relevant /etc/fstab available right now, but there's an explanation in this thread (see post #15): http://forums.slimdevices.com/showthread.php?t=26720

pski
2008-04-07, 18:33
thought this too, but not being a networking engineer I figured I'd stay out of the debate. I don't even have two lots of CAT6 to try the theory, albeit I'm going to be buying two reels for a roll-your-own home wiring as part of a renovation I'm planning.

I'm not a network engineer either. I just describe what's caused me trouble (I don't think I'm a geek, I prefer "early adopter.") If you're stringing wire, I'd go with the cat6 unless the price is prohibitive. Is there cat7?

I try to eliminate the easy causes of issues. Anything that takes "forever" compared to an earlier experience is usually caused by the things that have changed in the configuration.

To think of it, I'm usually the last to advocate a wire change: most "hifi" wire is a waste of money from a physics standpoint.

I would pound a network card, particularly an older card that might falter on super frames or a connection that might be suspect for the same reasons. (or a Windows config screen that lies about what it does...)

Whoseewhatsee is right: cat6 isn't required but it does eliminate a possibility.. (unless the catx is a cable bought from a retailer who pushes "super" quality cables (for $50) that might have a quality issue the same as the $5 cable...)

Also, my "real world" includes the fact that SMB on Linux is almost ALWAYs faster than than the same processor on ANY Windows version.

pski

MrSinatra
2008-04-08, 12:20
has anyone tried this on their infrant (or other) nas?

http://www.slimdevices.com/downloads/nightly/latest/trunk/

i wonder if infrant has in fact made the SC7 experience reasonable on their gear yet?

egd
2008-04-10, 05:18
While we're on performance, could you telnet to the Thecus and cat /proc/cpuinfo

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Celeron(R) M processor 1.50GHz
stepping : 8
cpu MHz : 1497.625
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx
bogomips : 2998.59

pski
2008-04-10, 19:45
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 13
model name : Intel(R) Celeron(R) M processor 1.50GHz
stepping : 8
cpu MHz : 1497.625
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe nx
bogomips : 2998.59

dang: 3k bogos... that thing should be beyond flying.

egd
2008-04-11, 04:00
dang: 3k bogos... that thing should be beyond flying.

It's a great solution for a large library, probably overkill for a small one.