guitarlp Posted May 4, 2008 Author Share Posted May 4, 2008 If it is software related, it is only for you. Doesn't seem strange? I stand by my original opinion. Hardware. Could be anything. Best test is to install some other OS on the SAME machine (don't touch anything, cables etc.) and test. Maybe some live Linux distro. Or some lite Windows. Try to copy some (large enough) zipped file to the array. Then run test on the archive as is on the array AND after you copy it back to your local machine. Messed up archived files are easier to spot than going over a video. And to my original test/question (because I don't think I got a clear answer): - You have a local video file that works fine. - You copy it to the array. - Your copy on the array stops playing ok? - You copy BACK FROM the array. - Your local NEW copy, plays ok? New Q: - Same file same artifacts at same place ALL the time? - If you copy on different disk on the array, still get artifacts? - Same or different artifacts? Two more extreme tests (first easier): #1 - Mount (see wiki on how) a normal NTFS disk on the array, WITH the video. - Copy LOCALLY on the array from that disk. - Try to play it. #2 - Install one of these: http://p-nand-q.com/download/rfstool.html http://rfsd.sourceforge.net/ #2a - Copy the file over the network to the array as you did all this time. - Take AWAY the disk from the array and install it on your windows machine. - Access it using the tools above. - Does the file work? #2b - First take away the disk and install it on windows. - Access it using the tools. - Copy the file locally from windows. - Play it from reiserfs fisk (on windows). Plays ok? - Put it back to unRAID. - Try to play it over network. Plays ok? All these will help pinpoint the problem. But need time. It could be that unRAID isn't working with my hardware correctly. Other people seem to be using the same hardware as me and have no problems though... but maybe they do and they just don't realize it. It's not like my movies don't play and return an error. If I were simply ripping DVD's, music, and data to the unRAID server like most I probably would have never noticed this issue in the first place. What would be interesting is to have someone with the GA-EP35-DS3R mobo rip a Blu-Ray movie (or possibly use some other 15+ GB file) and run the compare command to see what is returned. While I may be the only one reporting the issue, it doesn't mean that it can't exist and other people just haven't noticed it yet. Last night I coppied a movie to the unRAID server and ran the compare command. The result was that the file on the server was exactly the same as that on my local drive. I couldn't believe it. So I uploaded the movie again and re-tested... this time it errored on me like all the other times. Thank you for the walkthrough on more steps I can take to troubleshoot. I'm going to try Rob's steps first and see what that returns. Hopefully I get some usefull information from those tests because next I'll do everything you stated but that's going to be a lot more time consuming. I'll report back here though will all my results. Link to comment
RobJ Posted May 4, 2008 Share Posted May 4, 2008 These DOS tools like comp and fc are way too old to know anything about network paths or UNC stuff. You will have to map a drive, and preferably use very simple 8.3 paths and filenames with them. Sorry... Link to comment
guitarlp Posted May 4, 2008 Author Share Posted May 4, 2008 If it is software related, it is only for you. Doesn't seem strange? I stand by my original opinion. Hardware. Could be anything. I think we're all in agreement here. RobJ points to a very specific hardware issue with the chipset (and related driver). retry the wget (as below) and eliminate the windows station altogether. I tried copying wget-1.11.1-i486-1.tgz to my flash drive and once logged in via telnet running: installpkg wget-1.11.1-i486-1.tgz But it's saying: Cannot install wget-1.11.1-i486-1.tgz: package does not end in tgz Like I said before... I don't know my way around linux very well so dumb it down for me telnet to the unraid server, login as root cd to where you stored wget do an ls -l wget* if it is named incorrectly (as in two .tgz extentions) you can rename it with mv mv wget-1.11.1-i486-1.tgz.tgz wget-1.11.1-i486-1.tgz That's where I can't get to. How to I cd to my flash drive? Or how do I cd to my disk1? I've tried: cd /dev and then: cd md1 or: cd md2 but it returns that it's not a directory. I put the file on my flash drive but I could put it on disk1 if needed. I just need to know how to find the flash drive and the disk1 using a telnet session. Link to comment
guitarlp Posted May 4, 2008 Author Share Posted May 4, 2008 These DOS tools like comp and fc are way too old to know anything about network paths or UNC stuff. You will have to map a drive, and preferably use very simple 8.3 paths and filenames with them. Sorry... No problem. I mapped my disk1 folder as a Z: drive in windows. From the command promt, what exactly should I type? I removed the underscores from my file name to simplify the file naming structure. FCB MOVIE.ISO Z:\MOVIE.ISO FCB C:\MOVIE.ISO Z:\MOVIE.ISO Nothing I do seems to be working. Link to comment
guitarlp Posted May 5, 2008 Author Share Posted May 5, 2008 And to my original test/question (because I don't think I got a clear answer): - You have a local video file that works fine. - You copy it to the array. - Your copy on the array stops playing ok? - You copy BACK FROM the array. - Your local NEW copy, plays ok? New Q: - Same file same artifacts at same place ALL the time? - If you copy on different disk on the array, still get artifacts? - Same or different artifacts? 1st question: When I copy it to the unRAID server it becomes corrupt. When I copy it back to my PC it is still corrupt. 2nd question: Same file artifacts can be different and not all the time. If I copy to a different disk on the array the file is still corrupt. Pixelation/artifacts don't always happen at the same places... but sometimes they do. Link to comment
WeeboTech Posted May 5, 2008 Share Posted May 5, 2008 That's where I can't get to. How to I cd to my flash drive? Or how do I cd to my disk1? I've tried: cd /dev and then: cd md1 or: cd md2 but it returns that it's not a directory. I put the file on my flash drive but I could put it on disk1 if needed. I just need to know how to find the flash drive and the disk1 using a telnet session. flash is on /boot your data disks are on /mnt cd /boot or cd /mnt/disk1 type mount to see all mounted drives. Link to comment
guitarlp Posted May 5, 2008 Author Share Posted May 5, 2008 Ok... got it... thank you I did: wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.25.tar.gz But it returned: Resolving www.kernel.org... failed: Temporary failure in name resolution. wget: unable to resolve host address 'www.kernel.org; I installed wget and moved into my disk1 to download the file. Looks like unRAID is unable to access the internet? Nothing is blocking it on my router... thoughts? Link to comment
WeeboTech Posted May 5, 2008 Share Posted May 5, 2008 Sometimes you need to do it twice. Also do a cat /etc/resolv.conf capture the output and post it. if the second attempt does not work try by ip wget http://204.152.191.37/pub/linux/kernel/v2.6/linux-2.6.25.tar.gz Link to comment
guitarlp Posted May 5, 2008 Author Share Posted May 5, 2008 Sometimes you need to do it twice. Also do a cat /etc/resolv.conf capture the output and post it. if the second attempt does not work try by ip wget http://204.152.191.37/pub/linux/kernel/v2.6/linux-2.6.25.tar.gz Ok... I was able to download the file and then used gunzip to extract it. It said OK when it was done. Is there anything else I'm supposed to do at this point? Link to comment
WeeboTech Posted May 5, 2008 Share Posted May 5, 2008 You weren't supposed to extract it, just do gunzip -tv If there are no errors, then it was a clean download. Copy it to other disks and do the same test of gunzip -tv (filename.tar.gz). Link to comment
RobJ Posted May 5, 2008 Share Posted May 5, 2008 From the command promt, what exactly should I type? I removed the underscores from my file name to simplify the file naming structure. FCB MOVIE.ISO Z:\MOVIE.ISO FCB C:\MOVIE.ISO Z:\MOVIE.ISO The FCB batch file was designed to avoid having to type the filename twice, syntax: fcb testfile remotefolder becomes fc /b testfile remotefolder\testfile >>diffs. So your example should be FCB MOVIE.ISO Z: And I made a mistake in the batch file, reversed a backslash, should be: @fc /b %1 %2\%1 >>diffs Link to comment
guitarlp Posted May 5, 2008 Author Share Posted May 5, 2008 I have to apologize. EIther I changed something or I made an error earlier, but the unRAID server appears to both corrupt the file when it's written to disk and when reading from the disk (sending it to another PC). When I first used the compare command in command prompt the first couple of times it was coming back with the same exact errors every time. Today when I'm running it, sometimes it's returning the same errors, but most of the time it's different. Since the errors are the same sometimes it must be from writing to the disk. When the errors differ it's from reading from the disk. Anyways, I ran a couple of tests using the compare command and recorded my results. Test #! - New movie file uploaded to the unRAID server. Almost all BIOS features are disabled. Disks are running in IDE mode and SMART is turned off. Compare error at OFFSET 1BCD6560 file1 = 56 file2 = 54 (read the same file again and got the same errors above) Test #2 - Same BIOS config as above. Movie is deleted from unRAID and the same movie is uploaded again. Compare error at OFFSET 4F66F787 file1 = FD file2 = F9 Compare error at OFFSET 7C0EF887 file1 = EE file2 = 6E Compare error at OFFSET 9D66C607 file1 = E4 file2 = A4 (read the same file again) Compare error at OFFSET D05C5687 file1 = DC file2 = 5C Compare error at OFFSET A27C8607 file1 = D7 file2 = D6 Compare error at OFFSET A74C6687 file1 = 81 file2 = 1 Compare error at OFFSET EB1C6787 file1 = A4 file2 = A0 (read the same file a third time - NO errors) (read the same file a fourth time) Compare error at OFFSET 2C86C887 file1 = 3E file2 = 3A Compare error at OFFSET C6173887 file1 = 8A file2 = A Compare error at OFFSET 3D7EF687 file1 = B7 file2 = 27 Compare error at OFFSET 4B3C7707 file1 = 73 file2 = 53 Test #3 - Movie is again deleted from unRAID and re-uploaded. Compare error at OFFSET 1452B687 file1 = D1 file2 = 91 Compare error at OFFSET 9BBF0787 file1 = 17 file2 = 13 (read the same file a second time) Compare error at OFFSET B1FED607 file1 = A2 file2 = 22 Compare error at OFFSET 66BF0707 file1 = 99 file2 = 19 Compare error at OFFSET 400F7787 file1 = 90 file2 = 10 Compare error at OFFSET D51F5887 file1 = AC file2 = 2C Compare error at OFFSET 43DED807 file1 = 14 file2 = 10 I uploaded the movie from my HTPC (the one I've been uploading from) to my main PC in my office. Once on there I ran the compare command a few times and it passed every time. I then uploaded to my Windows Home Server (from the HTPC) and ran the comp command a few times. It passed every time here as well. From my main PC that now has an exact copy of the movie from my HTPC I ran the compare command to the unRAID server. Sometimes it passes, sometimes it fails. In the 4 time's I ran the test it only passed twice. It failed the other two times. I ran the FCB code posted by ROB and recorded the resuilts during two runs. The output of the results is posted below: Comparing files NA.ISO and Z:\NA.ISO 0B3F7787: DB DA 233EE587: F2 D2 6DFEE787: 8F 0F 8AD2A307: E0 60 E85F0707: B1 31 0000000178018607: 2D 25 00000001C3CEE807: 77 73 00000001F1183587: 3B 33 00000001FE3F0787: C5 C1 0000000203CEF787: 8B 83 0000000243DC8707: 91 90 000000028F9F0507: E3 E2 000000029EDEC507: E7 E6 00000002B4421787: CA C2 00000002B71F3787: 14 10 00000003753D7C87: B4 A0 00000003AD0EB807: 8A 0A 00000003BBA39787: 8D 0D 00000003CF26D587: 75 74 00000003D01F1807: CD 4D 00000004026F2907: 8C 88 0000000415170487: 2F 27 0000000415170507: 7D 3D 000000043DFEE787: F8 E8 000000044C16C687: 76 72 0000000458AEC687: A1 21 0000000499F6E707: 84 80 00000004BB1F3787: 0C 08 00000004C580C807: 0A 02 00000004C9DEC307: 79 71 00000004CEA4A687: BB AB 00000004DBEEC687: 14 04 00000004DF4F2687: 33 12 000000051D8EE607: C2 E2 00000005812F5607: 04 00 Comparing files NA.ISO and Z:\NA.ISO 26EF0707: 14 10 000000013DAEC707: 67 27 0000000146DC9587: D9 58 000000017C9EB607: 1D 19 0000000188EF5607: 64 60 000000021026C687: AF 8B 00000003044F2687: EB 6B 0000000318D5D587: 17 07 0000000333DF1707: 5D 4D 00000003A0EF0787: E3 C3 00000003B9FF1687: ED C5 00000003BA8ED587: 0C 08 00000003F14EE687: C3 43 00000003F226D607: 9F 9B 000000040CAF1707: 34 14 0000000491BED687: E6 66 00000004C14EF587: 96 16 00000004CD0F2407: D7 D3 00000004D314C507: 55 44 00000005510EE807: 6A 62 If anyone needs me to test something else please let me know. Hopefully these results can narrow things down a bit. Link to comment
guitarlp Posted May 5, 2008 Author Share Posted May 5, 2008 I just ran the FCB script from my HTPC comparing the movie to the movie I transfered to my main PC earlier. It returned the following (I ran it twice): Comparing files NA.ISO and X:\NA.ISO 0EB6FFF6: D6 D4 000000011FE6FFF6: D2 D0 00000001DFAAFFF6: D7 D5 00000002535EFFF6: 4F 4D 000000035F4DFFF6: 87 85 000000044104FFF6: 82 80 000000050E04FFF6: C2 C0 Comparing files NA.ISO and X:\NA.ISO C9BBFFF6: A6 A4 000000031BF7FFF6: 4E 4C 000000037468FFF6: B6 B4 00000003764AFFF6: EA E8 00000004D308FFF6: 36 34 So... could this be the switch between these PC's causing the issues? The PC does have a lot less errors then the unRAID server. If the switch is glitching or something every once and a while maybe the unRAID server handles these errors worse then windows based PC's do? I'm going to try running FCB from my main PC to the unRAID server to eliminate my HTPC from the equation. I'll post back the results. EDIT: So I ran the FCB script twice from my main PC to the unRAID server. The file on the unRAID server is the same one that's been on there during most of my testing today. The file on my main PC is the one I transfered from my HTPC over my network earlier today (should be an exact match to the file on the server. Here is what FCB spit out: Comparing files NA.ISO and Z:\NA.ISO 24482787: 2D 29 33682707: C9 49 0000000132D7C807: 67 63 000000024D27E507: D0 C0 00000002B8BA0807: 46 02 00000002F2785887: E5 65 000000030547E687: A7 A3 00000003CD3FF907: 80 00 00000003D768160F: D0 C0 000000041E084687: EF 4F 000000042C128607: 51 50 00000004776D8587: 1D 19 000000051ECC0687: ED E9 Comparing files NA.ISO and Z:\NA.ISO 248E0687: BF B7 0000000111B80807: 1D 19 0000000115E03687: 98 90 00000001D8A7C887: 0B 0A 000000030ABD8687: 2B 23 000000035957D787: A2 22 000000043C9BF787: 84 04 00000004CAAFB707: 3D 35 EDIT 2: Clearly the HTPC to the unRAID server is getting more errors then my main PC to the unRAID server. They're all attached to the same switch. The onyl difference being the HTPC is connected to the switch via a 100 ft cat6 cable while the unRAID server is connected by a 50ft cat6 and the main pc by a 25 ft cat6. Cat5e should be able to do runs up to about 350ft. I'm well below that so that shouldn't be the problem. I only mention this because for some reason my HTPC seems to be getting more errors then my main PC. the HTPC is running x86 Vista Home Premium and my main PC is running x64 Vista Ultimate. Link to comment
SSD Posted May 5, 2008 Share Posted May 5, 2008 So... could this be the switch between these PC's causing the issues? The network would be my last guess as to the cause. The network uses protocols that are supposed to avoid errors like this. Anything is possible, but this is unlikely IMO. My first thought is that the drive cables are bad. Are these SATA drives or IDE drives? A number of people running IDE drives with round data cables have had similar problems (including me). These cables are are sold as premium but actually do not meet spec. unRAID seems to stress them more than Windows. If this is you, I'd recommend replacing your cables with the more traditional flat cables. If they are SATA drives, I would double check all the connections. Replace the SATA cable to the drive you are writing to. You could try copying large files locally (on each of your machines) to see if you can reproduce the problem without the network being involved. This would eliminate one more variable. These kinds of problems are frustrating! Good luck. Link to comment
guitarlp Posted May 5, 2008 Author Share Posted May 5, 2008 So... could this be the switch between these PC's causing the issues? The network would be my last guess as to the cause. The network uses protocols that are supposed to avoid errors like this. Anything is possible, but this is unlikely IMO. My first thought is that the drive cables are bad. Are these SATA drives or IDE drives? A number of people running IDE drives with round data cables have had similar problems (including me). These cables are are sold as premium but actually do not meet spec. unRAID seems to stress them more than Windows. If this is you, I'd recommend replacing your cables with the more traditional flat cables. If they are SATA drives, I would double check all the connections. Replace the SATA cable to the drive you are writing to. You could try copying large files locally (on each of your machines) to see if you can reproduce the problem without the network being involved. This would eliminate one more variable. These kinds of problems are frustrating! Good luck. Unlikely? I seem to be getting errors with this 22 gig file between all my PC's when running the FCB script. Cutting the unRAID server out of the equation stills gets me errors running FCB. Knowing that, doesn't it sound like a network problem? Maybe my switch is dropping packets or something. Maybe something just isn't working exactly like it should. All my drives are SATA. I have tested with a bunch of different SATA cables as well... the different cables didn't make a difference. I think I may take your advice and transfer this movie to a USB storage drive. I can then move that file around my PC's and a run a few tests to see if the errors are more write or read related. Although from the errors I've been seeing from these last few tests, it seems read related because errors don't seem to be repeating themselves anymore. I'm removing my gigabit switch and attaching my unRAID server and main PC directly to the router. It's only 10/100 speed though... so I have a feeling this will take a while. But I'll run it 2-3 times and report back if it does anything different. Link to comment
SSD Posted May 5, 2008 Share Posted May 5, 2008 Will be interesting to see how this turns out. My experience with network gear is that either it works or it doesn't. Spurious data corruption is more normally a cabling thing. I have had some Cat5 cables go bad. If you really think it is this switch, it would be easy to go to CC and buy a new Gigabit switch. If it works, problem solved. If it doesn't, return it and you know it wasn't your switch. This might save you hours of copying your 22 gig file around. Link to comment
guitarlp Posted May 5, 2008 Author Share Posted May 5, 2008 One pass of the FCB script without my switch (cables connected directly to my router) gave me the following output: Comparing files NA.ISO and Z:\NA.ISO 0000000121A7F687: 8C 88 000000013FB7D807: 11 10 I'm not even sure if those are errors per say. Some "errors" look like: 248E0687: BF B7 and some have a bunch of 0's in front: 0000000121A7F687: 8C 88 Hopefully someone can clear that up. But so far, after one pass, it's clear that there's a lot less being reported by FCB when connected directly to my router. Link to comment
SSD Posted May 5, 2008 Share Posted May 5, 2008 These are compare errors. 0000000121A7F687: 8C 88 In this example, 0000000121A7F687 is the position in the file (in hex), 8C is the byte value at the position in one file, and 88 is the byte position in the other file. 88 = 0100 0100 8C = 0100 1100 So there was a 1 bit difference. On the other one ... 11 = 0001 0001 10 = 0001 0000 One bit difference on that one also. This is serious. You have to be able to make perfect digital copies of files. Period. Couple of random questions: Are you overclocking? Have you run memory tests? My experience in doing troubleshotting is that you have to get back to something that works. For you, maybe that is a single workstation able to copy that monster file from one disk to another - perfectly - 3 times in a row. Then do the same on your unRAID server. Once you are sure they are working, start doing tests involving as few new variables as possible. As each test passes and you are confident, take the next step. When you can say "I did this" and it worked over and over, and "when I tried this tiny change" it broke over and over, the problem will likely be obvious, even if unlikely. Link to comment
WeeboTech Posted May 5, 2008 Share Posted May 5, 2008 I doubt it's the network switch either. (Unless it is reconstructing packets) There are protocols in place to safeguard network delivery. There are specific fields created to hold a checksum of the data. TCP/IP is defined as a reliable delivery mechanism, UDP is not. When you downloaded the wget and did the gunzip, it proved that network wise you could download a large file and decompress it (Unless you did not tell us about errors). However many PC's are in your network, you're going to need to create a truth table of Which pc's transfer to which pc's and if your file compare was good or bad. I think some of this is a lil beyond unRAID. Although it's an interesting task to determine. You should also document the basic hardware in each machine. Perhaps you need to test the ram out in the client machines. I would suggest you try an FTP into unraid from your windows workstation. Turn on hash marking so you can see the transfer. If it starts to pause and slow down really bad, then there is a network issue. If it runs along happily at a decent clip continuously, then network wise you are ok. > I think I may take your advice and transfer this movie to a USB storage drive. After you copy it to your USB storage drive, do an FC between the source and the USB drive. be sure you have apples and apples. Link to comment
RobJ Posted May 5, 2008 Share Posted May 5, 2008 Those leading zeros on many of the fc results are certainly annoying, and I don't recall ever seeing them. But then, I probably only used mostly 2 gig files, and a few almost 4 gig files that must have been just under the 4 gig size. When your error addresses went over the 4 gig mark, then the address needed 9 hex bytes, so fc.exe switched to a quadruple-wide display format, instead of the double-wide format with 8 hex digits. This must have been a recent NTFS enhancement to the tool, because back in the DOS days when fc.exe was actually being used, no one would have even comprehended hard disk partitions over 4 gigs in size, let alone files that big. You have some very interesting observations, from which I can't make any conclusions, but can provide some patterns. All I/O involving the unRAID server is using a 128 byte buffer, addresses all end in 07 or 87, with almost all of the errors involving a byte at offset 07 within that buffer. Only one error occurs at offset 0F, 8 bytes higher. Almost all involve only a single bit error, with only 2 having 2 bits changed (could have missed another). Statistically, there is a very high number of errors involving the 80 and 04 bits. Numerous other bits are involved, but only in very small counts. The I/O between the HTPC and Main PC uses a 64K buffer, with error byte at FFFC, always. Since statistically the bit errors only occur once per buffer, that may explain why so few between those 2 machines. The only bit involved is the 02 bit. The enormous difference in the sizes of these buffers is a bit mind boggling to me. I cannot think of any process using a negotiated buffer size, that could result in 2 buffers so hugely different, 128 vs 64K. The fact that the error offset is so consistent, yet different between the 2 buffers, is also very interesting, but I can't come up with any possible scenarios to explain it. Will continue to analyze... Perhaps my observations will stir an idea in someone else. The distribution of the addresses appears to be completely random, with no observable pattern. Some are closer, some are far between, so no conclusions about the timing of the errors can be made. However, the fact that they obey such strict rules in the patterns observed, means there cannot be a random source of corruption. No electrical interference or other cable issues could cause something so regular. This is clearly buffer related somewhere. This is clearly programmatic, whether in a software program or driver, or in a firmware routine in hardware. I agree with WeeboTech, you need to begin a table of all components, machines, and paths. I would recommend adding one more computer to the mix. What you want to do is find a pair of computers that can compare files perfectly between them, with absolutely no errors, ever. When you do, you immediately can trust both machines AND components AND paths between them. That gives you a solid base to test the rest. It makes it much easier to isolate the common component that is always involved in compare failures. I agree with Brian about the seriousness of this. Not one bit error is acceptable, ever. Ever, ever. Period too. Link to comment
NLS Posted May 5, 2008 Share Posted May 5, 2008 Did you try a different NIC? (both sides but first would check unRAID side) Link to comment
WeeboTech Posted May 5, 2008 Share Posted May 5, 2008 I say, document what you have first before changing out hardware. There might be something that stands out. If doing the wget on the kernel then doing the gunzip -tv was successful, then the network seems to be OK. (At least on that hardware path). Link to comment
guitarlp Posted May 5, 2008 Author Share Posted May 5, 2008 Thank you for the replies everyone. To answer some questions, none of my PC's are overclocked. I always run everything at stock speeds. I've used both the onboard LAN and an Intel Gigabit NIC in the unRAID server. When I downloaded the file onto the unRAID server with wget and then used gunzip no errors were displayed on the screen. I'll do some more tests between all my PC's and I'll add my laptop and maybe my old HTPC into the mix as well. That will give me 6 PC's total to compare results between. Link to comment
guitarlp Posted May 5, 2008 Author Share Posted May 5, 2008 Also... I just did 3 runs of FCB going from my main PC to the unRAID server (without using the switch... these are connected directly to my 10/100 router). Here are the results: Comparing files NA.ISO and Z:\NA.ISO 0000000121A7F687: 8C 88 000000013FB7D807: 11 10 Comparing files NA.ISO and Z:\NA.ISO FC: no differences encountered Comparing files NA.ISO and Z:\NA.ISO 000000021CFFE807: 3D 2D There are still errors... but clearly less errors then with the gigabit switch put into place. With the gigabit switch I got the following (in 2 tests with FCB): Comparing files NA.ISO and Z:\NA.ISO 24482787: 2D 29 33682707: C9 49 0000000132D7C807: 67 63 000000024D27E507: D0 C0 00000002B8BA0807: 46 02 00000002F2785887: E5 65 000000030547E687: A7 A3 00000003CD3FF907: 80 00 00000003D768160F: D0 C0 000000041E084687: EF 4F 000000042C128607: 51 50 00000004776D8587: 1D 19 000000051ECC0687: ED E9 Comparing files NA.ISO and Z:\NA.ISO 248E0687: BF B7 0000000111B80807: 1D 19 0000000115E03687: 98 90 00000001D8A7C887: 0B 0A 000000030ABD8687: 2B 23 000000035957D787: A2 22 000000043C9BF787: 84 04 00000004CAAFB707: 3D 35 So, why am I getting less errors without the switch? What could explain that? I think that's a pretty good place to start. Link to comment
WeeboTech Posted May 5, 2008 Share Posted May 5, 2008 Robj mentioned something about nforce chipsets and corruption. It would be interesting to see the mix of motherboards you are working with. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.