NT seems to have a difficulty along the lines of recognizing partitions greater than 500MB as per this article: http://support.microsoft.com/search/preview.aspx?scid=kb;en-us;Q124307
But, MS suggests using ontrack software as in this article
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q124910 to work around it.
It's a start.

Thanks, however both of those articles apply to NT 3.5.
 
NT 4.0 seems to be more capable, yet it may be simply a driver or a setting that I'm missing -- I understood the hard-drive limitation to be 2 terabytes... see MS article Q114841:
 
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q114841
 
"With a standard sector size of 512 bytes, the 32 bits used to represent the Relative Offset and Number of Sectors translates into a maximum possible partition size of 2 terabytes or (2,199,023,255,552 bytes)."

Re:
 
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q114841
 
Interesting note, aside from the fact that the 1999 article is referring to ATA IDE technology up to ATA/100 ...
 
Drive and Controller Types
 
"IDE drives use a different data structure for representing the number of cylinders, heads, and sectors per track than the partition table and BIOS INT 13 interface. According to the IDE specifications, the maximum number of cylinders is 65536, the maximum number of heads is 16, and the maximum number of sectors per track is 255. This yields a maximum of 136.9 gigabytes, ..."
 
Yet the BIOS & POST still indicate 163,928 MB, which I'm hoping could simply be a DRIVER error... because the hardware is indicating that it is feasible to access the entire hard-drive...

Note about performace of ATA/133 over ATA/100, speaking from experience.
 
Throughput bandwidth performance is negligable between the two, and considering that 133 MB/s is the complete bandwidth of the PCI BUS, I'm not surprised that the ATA/133 offers little over the ATA/100.
 
The purpose I'm attempting to achieve, from use of the ATA/133, is jumping the size limits of ATA/100. I'm sure sizes of HDD's will continue to grow...

Don't know if this has any relevance. http://www.maxtor.com/products/UltraATA100/TechSupport/TechProcedures/23004.htm While this is talking about a Maxtor Ultra ATA, the installation of the drivers is to take place prior to the drives being connected. "Hard drives should not be connected to the Ultra ATA/100 Adapter Card before performing the following procedure.
 
The UDMA 100 drivers must be loaded on the system hard drive (running under the existing hard drive adapter) before any hard drives are connected to the Ultra ATA/100 PCI Adapter Card."

Hmmm.... This may be the beginning of a solution...
 
BUT, what happens if the drives were attached BEFORE the drivers were installed?
 
Undo with DELPART.exe ?
 
Will keep this board posted with my results....

http://maxtor.custhelp.com/cgi-bin/maxto...nZT0x&p_li=
 
If that specific URL doesn't work, the one to the Maxtor Knowledge Base Search Engine is:
 
http://maxtor.custhelp.com/cgi-bin/maxtor.cfg/php/enduser/std_adp.php?p_faqid=960%20
 
The Info I found was:
 
Windows NT 4.0 Service Pack 3 was the first service pack from Microsoft to contain the required updates to support Ultra DMA (Ultra ATA) transfers. However, Service Pack 5 is now recommended as the minimum. The DMACHECK.EXE utility located on the Service Pack CD will need to be installed in order to enable DMA transfers for the operating system. See your motherboard manufacturer or host controller manufacturer for the latest NT software drivers for your specific host or ATA chipset.
 
Since I've only got SP4 on the puppy, I'll grab SP 6a, give it a try, and keep the board informed of my results...

Same old 131,069.
 
ASUS has not replied, have now reqested help from MAXTOR. MicroSoft no longer supports NT 4.0.
 
BTW... the URL in my prior post:
 
http://maxtor.custhelp.com/cgi-bin/...?p_faqid=960%20
 
*DOES* take one to the correct specific Maxtor KB solution for Intel chipsets...

May i ask why you are running NT 4.0 on an A7V333 MB?

Because it's cheap enough, and I happen to know just enough to know how to get done what I want to do...
 
I truly would like to move on to at least some version of Linux, and preferably UNIX.
 
Alas, there are other things than living with one's head in the computer... and so these wishes are simply lower priorities...

Hey Dale, how is that Asus A7V333? I noticed that this is one of the only boards loaded with so many good features like optional RAID, but firewire, ATA133, and USB 2.0, how well does it perform? Is it stable?

I can't seem to push it much past 140 MHz FSB, and keep it around 137 MHz, for stability reasons...
 
My test is copying 130 GB of data from drive to drive... if it makes it the whole way through, then that is the FSB that I use....
 
I'm currently testing different sector format sizes for optimum byte transfer rates for the file sizes that I have.... have found that at 1,024 bytes, transfer is around 24 MB/s to 27 MB/s. This works out to be around 100 GB/hour...
 
At 2,048 bytes/sector, I can get more files in less space, but transfer rates from drive to drive (different channels) drops to around 80 GB/hour...
 
It certainly has one sh*t load of I/O possibilities... and if I can get this puppy to read the entire 163 GB of these Maxtor drives, will probably wind up keeping this for some time...
 
The other 'sweet' spot for me is that it takes the AMD XP CPU, which seem to take more heat without crashing... whether it was timing issue or not, never seemed to get the older Athelons to handle much over 60 decrees Celcius... and this one has been upwards of 64...
 
HTH

SO your running an Athlon XP, with NT 4.0 and overclocking?
 
 
If that be the case then I have to question your sanity.
 
THe only reason I can see running Nt 4.0 is for Stabilty reasons, and the fact your using a VIA based board rules that out. Then overclocking on top of that makes no sense whatsoever.

I hardly class running a 1400 MHz CPU at 1438 MHz as 'overclocking,' although *technically* you are correct -- by 3%!
 
The priorities are $$ first, and NT 4 with AMD CPU's gets me a decent $/performance ratio -- and the cranking of the FSB from 133 to upwards of 166, or even 180 MHz, as I've seen isn't what I'm chasing...
 
Wanted to mention another beauty about this MoBo -- is the DDR RAM capability... all the way to PC2700.
 
I do not question your assessment of my sanity.
 
My initial response from MAXTOR, although quite prompt, did not work. They had suggested that the drive would have to have multiple partitions, so I partitioned 80 GB, formatted and rebooted, [as they suggested] to see the balance jump from 50 GB to 80 GB.... DIDN"T WORK.

My only point being, that NT 4.0 cannot take advantage of the features of that board. At the very least you'd have to be using Windows 2000 to get the most out of it.

USB 2.0 & 1394... agreed...
 
Don't have *that* many toys... however, I'd like to be able to stuff it with 8 HDD's each 160+ GB.... and turn this puppy into a troublefree File Server...
 
I've got some kind of 1 MB AGP video card hooked up to a 800x640 monitor -- [hay ! at least it's color!]
 
I don't even use the on-board Audio, could put the on-board NIC to use I suppose, but I think it's more of a fact of a I/O feature packed board, [in relation to finding a board that more accurately matches my needs] whereas I wanted to be able to access the UDMA/6 -- otherwise known as ATA/133 drives... not so much for the marginal bandwidth improvement... but for the anticipated lack of SIZE limits...
 
It was the first MoBo available from ASUS, with the AMD CPU socket that featured ATA/133, and I've got to say that I'm happy with the quality of their boards... I've currently have 3 other boxes with their MoBo's, two of them running PPro's -- if that gives you some idea of the date of *that* technology...

Just had my second email reply from MAXTOR, their current solution is to contact Microsoft for a solution. Microsoft no longer supports NT 4.0. No solution will be forthcoming from MS, short of the KB article posted above.
 
I was retesting the HDD performance and noted some errors in prior posts, as well as a lack of my ability to duplicate prior performance.
 
The sector size that I have is 2,048 KB per sector. The performance from slave on primary to slave on secondary IDE I produce is in the 20 MB/s to 24 MB/s. I have 2,848 files on 135 GB -- ranging from 30 MB to 700 MB in size, *.mpg digital videos. This results in something like 2 hours to copy one drive to the other, or some 80 GB/hour.
 
There does NOT appear to be significant performance differences between 4,096 byte sectors and 2,048 byte sectors, but either one of these sector sizes produce twice the performance of 1,024 byte sectors.
 
I pull these figures out of my head, and because I [& others] do acknowledge my cognitive abilites [sanity] am known to make errors...
 
I am hoping to provoke MAXTOR to assist in a solution, seeing as Microsoft is out of the picture, and the ASUS appears to be working -- as indicated by the BIOS & POST.
 
Since it also appears that the functionality of how the O/S interacts with the hard-drive has not changed from NT 4.0 to Windows 2000, I do NOT see any apparent advantage to upgrade the O/S, especially given the differences in cost...

There are several different reasons why a filesystem might be limited to a certain size.
The old 500 MB partition size problem was caused by MS' FAT16 partition, because of the hard limits in the FAT table it would only recognise 500 MB of disk space, irrespective of the size of the disk.
Microsoft removed that limitation with the release of FAT32 and later NTFS. FAT32 and NTFS will recognise much larger partitions, at least 2TB. So that is not your problem.
I think you're running into the IDE LBA limitations. The *IDE* BIOS stores disk sector information. With the old IDE CHS method you were limited to 2GB drives. Ontrack (and others) came up with software that faked things out. They ran in the disk's boot sector, and "patched" the BIOS before the O/S ran, allowing you to use disks >2GB with older IDE firmware.
IDE manufacturers later came out with LBA, a newer method of addressing disk sector information, which is 32 bits if I remember correctly and will allow you to access disks of up to 132 GB.
The method of accessing physical sectors on the disk (CHS, LBA, etc.) has NOTHING to do with ATA 33/66/100/133. Those are bus standards for communicating from an IDE controller to and IDE drive.
Sometimes manufacturers can upgrade the IDE firmware or BIOS to handle a new sector allocation scheme, mostly though, they just wait for the next rev of their controllers to implement it.
When Maxtor created the new ATA/133 spec they also came up with a new sector method, I don't remember what it's called now, but it's larger than the 32 bit LBA, I think it's 36 bits or something like that. In order to access the full 160 GB per disk you have to be using a controller that supports the new larger sector addressing scheme, which is why Maxtor was shipping their 160GB disks with a Maxtor ATA/133 controller with onboard BIOS. Obviously you didn't get that combo.
You've got a new KT333 mobo, which I think you said has ATA/133 support. You need to check and see if the BIOS supports (or has newer firmware) for the sector addressing scheme. Check the BIOS, you will usually see Large, LBA, and something else. If you can't do that then you need to get a controller that supports it. As I mentioned, Maxtor has one. Changing the sector addressing WILL MAKE ALL EXISTING DATA INACCESSABLE.
So in conclusion, it's not NT or the driver's fault IMHO. And for my last $.02, NT 4.0 is a great OS. Not as compatible as 2k or PnP support, but still, if installed right, it makes a damn good OS.

Quote:
Microsoft no longer supports NT 4.0.

Then why persist with it?

Re: "thekourier"
 
Decent analysis...
 
Yes, the ASUS A7V333 provides ATA/133, as the BIOS and POST both acknowledge. It winds up being 19,929 / 255 / 63 CHS x 512 Bytes/sector = 193,928 MB.
 
On this track at looking at the LBA in the BIOS, I experimented with the following.
 
I set the HDD type to USER, and was now given the choice of setting the TRANSALATION METHOD:
- LBA CHS CAP resets to 8422 MB
- LARGE CHS CAP resets to 7927 MB
- NORMAL CHS CAP resets to 528 MB
- MATCH PARTITION TABLE CHS CAP resets to 528 MB
- MANUAL set C = 19,929 / H = 255 / S = 63
 
POST still reports the drive as 163,928 MB.
 
DISK ADMINISTRATOR *still* only sees 131,069 MB, and can still see the DATA, FOLDERS, etc on the drive...
 
HMMMM....
 
WHY PERSIST?
 
Well, if I hadn't of persisted on prior occasions, the I wouldn't have been able to map drives from an IIS 4 FTP server onto the FILESERVER.... given the MS interface, until I found an undocumented solution -- about a month later.
 
I cannot even begin to recall all of the other solutions that I either eventually found, or discovered that there was no solution -- at all.
 
So, this is the *beginning* of why I persist.
 
Other reasons are the alternatives. If I were to acquire a SCSI RAID box (the box for 12 drives alone) would be in the area of $3,500 CAD + 14.5% taxes alone. Each 70 GB SCSI 3 drive would be around another $1,100 +14.5% taxes... which is fine if I have unlimited resources -- which I don't.
 
*IF* I can manage to get this UDMA/6 or ATA/133 accessing over 127 GB limit (well, the ATA/100 limit -- different actual MB #'s depend on who's counting what, in binary or decimal mode), then I have in mind placing 6 x 160 GB HDD's in a software RAID 5, which will give me *some* kind of fail-over, in case *one* drive fails, to recover the data with a minimum of cost.
 
So far the FileServer has cost $600 - $700, plus the cost of drives. The 160 GB Maxtors currently run as low as $400 CAD / drive OEM.
 
Six (6) drives in a RAID 5 will provide me with an estimated 800 GB of storage in one volume set, with fail-over.
 
So the entire 800 GB of storage will be in the range of $3,000 CAD, well withing the feasibility range of my resources as a volunteer for the IIS project, and I contribute both the knowledge, hands on time, and the funds...
 
Does this help to explain, why?
 
 
I currently speculate that the solution lies in how the O/S is accessing the information in the MBR, and whether the solution becomes yet another overlay file (like for the older, 'NORMAL' drive limit of 528 MB), creating a driver that translates the MBR information into a form that the O/S can use to access all the way to 2 terabytes, or even toying with the BIOS settings manually (like I just tried, but have not attained a solution -- yet) ... or some-such....