My experiences with hpt366

Peripherals, parts, data storage...
Post Reply
Posts: 3
Joined: Fri Feb 11, 2005 2:52 pm

My experiences with hpt366

Post by noph » Thu Jun 22, 2006 2:26 pm

Today I did some testing with the hpt366 controller:

I have two discs, two maxtors as mather of fact. On older 15gig and a newer 20gig disc.

did some testing in linux with hdparm. worth mentioning is that I was not running PREEMPT and no Desktop-scheduler. Just most throughput-io-schedulers.

That shouldn't anyway affect the results of my hdparm testing.

the first drive: the 20 Gig did: 22 meg/s
the second: the 15 gig did: 26 meg/s

udma3 or udma4 didn't affect perfomance at all.

Thought this was kind of weird as I wasn't close at all filling the ata66 buss.

Tried with a newer 120 gig disc. result: 29 meg/s

This seemed very weird as i'm quite sure that disc can spit out more.

Benchmarked it with nvidias nforce4 driver on my desktop-computer and it could hold: 57 meg/s substained speed.

hmm, tried my 20 gig disc with the nforce4 controller and got 41 meg/s substained speed.

these values seemed more real.

Though that perhaps the hpt366 just slices its bandwidth. like 66 meg/s / channels. so i get 33 meg/s on each cable.

To test my theory I hooked both the discs on separate channels on the hpt366 and tried to run two hdparm -t's simultaniesly(?)

Seemed to work fine for a few tests, then something weird happened.

DMA totaly crashed on one of the first disc. hde in this case. still worked fine on the hdg.

turned on the dma again with hdparm on hde and tried again to do hdparm tests. The kernel starts to spit out loads of DMA errors and such. The hdg reported no problems what so ever and still performed good but the hde went down to 3.5 meg/s.

this was quite weird as the DMA worked fine for like two or three tests and then broke down. And during those tests that worked, both discs gave ~24 meg/s

Conclusion: the hpt366 is very bad. The harddrives can give more than the hpt366 can handle. And you have to look out for the dma to lockup.
Had plans run Software raid on the controller but as it seems now there is no point.

Sorry for my poor rush-english. :)

Posts: 30
Joined: Wed Jun 21, 2006 11:21 am
Location: Uk , North Yorkshire

odd happenings

Post by headspirit » Thu Jun 22, 2006 2:36 pm

ive had some problems with this controler on other boards with larger drives , and now i have a bp6 that im useing as a file server i dont bother with the hpt366 , i use a pci udma 100 controler and that works a treat

im useing the latest bios revision Rv with the highpoint 1.30 update

ive considered pluging my cd rw and dvd into it put theres no point really , not like thay can take advantage of the extra speed anyway
Reality aint what it used to be

Posts: 3
Joined: Fri Feb 11, 2005 2:52 pm

Post by noph » Thu Jun 22, 2006 2:58 pm

Noticed that i forgot posting my bios-thingies

biosverion: the latest posted on the board 2006-06-22

and the linux kernel is

Posts: 1043
Joined: Fri Feb 13, 2004 2:30 am
Location: Houston, TX

Post by davd_bob » Thu Jun 22, 2006 4:35 pm

Two parameters of biggest concern on HDs are RPM and the cache size.

8Meg cache on a 7200rpm set to ata33 will usually out preform 5400RPM with a 512K cache set on ata66.

That ata rating is mostly a hype parameter manufacturers use. Dont get me wrong, there is some truth in it but you will be hard pressed to get 40meg rating for longer then a second on any drive no matter what the ata rating.
There are *almost* no bad BP6s. There are mostly bad caps.

No BP6s remaining
Athlon 2800
Sempron 2000
ViaCPU laptop with Vista.(Works great after bumping ram to 2Gig)
P-III 850@100

Posts: 46
Joined: Sun Aug 28, 2005 10:36 am

Post by s4brains » Sun Jun 25, 2006 10:54 am

It is my belief that the Linux kernel uses a software sector translation scheme with the HPT366 (similar to an Ontrack Systems approach) since no firmware BIOS exists for this controller that provides for large LBA (48 bit) required to support large capacity drives.

I suspect that all disk I/O for this controller is routed through the sector translation algorythm without regard to the "actual" disk size and this will have a significant impact on the transfer rates because software sector translation isn't very fast. This would also explain why the choice of UDMA setting didn't produce a noticeable effect. Sector translation is creating a "bottleneck".

Best Regards,


Posts: 3
Joined: Fri Feb 11, 2005 2:52 pm

Post by noph » Tue Jun 27, 2006 7:33 am

davd_bob: yeah thats true. but i assumed those wouldn't so big. i'm not even sure the cache is even used.

is it the hdparm parameter read-ahead that fills the cache?

well, anyway.

i can try hdparm with my newer computer and see what that will result in. I bet it will be somewhere around 40 meg/s.

Posts: 110
Joined: Mon Jul 29, 2002 3:32 pm
Location: Hertfordshire UK

Post by g0fvt » Mon Jan 28, 2008 7:08 pm

I have not benchmarked my Highpoint on Linux... but the later posts here may explain something I have experienced.... IE that I have been running a pair of 250Gb drives on my Highpoint controller (OpenBsd) for some years and not seen any real problems even when filled beyond 200Gb each.... mind you recently I have moved most of the data onto another machine only to find that 2 movie files refuse to transfer.....

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest