CHS, LBA, performance (was: ELF Bootloader)

bluemoon · Post by **bluemoon** » Mon Nov 19, 2012 7:30 am

SparrowOS wrote:Modern hard drives use CHS internally

Learn to read please. whether the hardware use CHS representation internally is open to implementation, but sure such CHS geometry, if any, is different to BIOS's CHS which is limited to 2GB.
Furthermore, for SSD driver the CHS geometry make no sense at all.

SparrowOS wrote:otherwise how would they access cylinder, head, sector?

Now you are asking question. I'll leave this for the expert.

By the way, we have enough trolling and off-topic, and I believe the original poster got his answer, and been pointed to related reference materials, I hereby request a lock.
If you are interest in how hard-disk work you should open up a new thread.

rdos · Post by **rdos** » Mon Nov 19, 2012 7:34 am

SparrowOS wrote:
Combuster wrote:
SparrowOS wrote:And CHS is faster still! because... the drive doesn't have to do the math.
Proof wanted.
I was mocking him. Why would 28-bit be faster than 48-bit?

Because it needs fewer IO-instructions. IOW, it assumes the driver uses PIO-mode. For DMA-mode, there would be little if no difference.

SparrowOS · Post by **SparrowOS** » Mon Nov 19, 2012 7:50 am

rdos wrote:
SparrowOS wrote:
Combuster wrote:Proof wanted.
I was mocking him. Why would 28-bit be faster than 48-bit?
Because it needs fewer IO-instructions. IOW, it assumes the driver uses PIO-mode. For DMA-mode, there would be little if no difference.

CHS is faster still becauase the hard drive gets to work faster because it does not have to convert it.

bluemoon · Post by **bluemoon** » Mon Nov 19, 2012 8:39 am

This is so extreme that I request a quadruple facepalm...

SparrowOS · Post by **SparrowOS** » Mon Nov 19, 2012 9:00 am

1 I/O is roughly 1uS

Doing PIO
For 28LBA it's about 5 to set-up
For 48LBA is's about 9 to set-up
Seek time is what? 1000uS?
One block is 512/4 = 128 to transfer
You can do multiple blocks, too.

rdos · Post by **rdos** » Mon Nov 19, 2012 4:00 pm

SparrowOS wrote:1 I/O is roughly 1uS

Doing PIO
For 28LBA it's about 5 to set-up
For 48LBA is's about 9 to set-up
Seek time is what? 1000uS?
One block is 512/4 = 128 to transfer
You can do multiple blocks, too.

Seek time is zero for a compact flash.

SparrowOS · Post by **SparrowOS** » Mon Nov 19, 2012 4:06 pm

rdos wrote:
SparrowOS wrote:1 I/O is roughly 1uS

Doing PIO
For 28LBA it's about 5 to set-up
For 48LBA is's about 9 to set-up
Seek time is what? 1000uS?
One block is 512/4 = 128 to transfer
You can do multiple blocks, too.
Seek time is zero for a compact flash.

I'll bet it uses 48-bit LBA because it's new.

I'm not sure you can use 28 on a 48 bit device.

rdos · Post by **rdos** » Mon Nov 19, 2012 4:12 pm

SparrowOS wrote:
rdos wrote:
SparrowOS wrote:1 I/O is roughly 1uS

Doing PIO
For 28LBA it's about 5 to set-up
For 48LBA is's about 9 to set-up
Seek time is what? 1000uS?
One block is 512/4 = 128 to transfer
You can do multiple blocks, too.
Seek time is zero for a compact flash.

I'll bet it uses 48-bit LBA because it's new.

If I remember it correctly, every disk must support 24-bit LBA (if it isn't very old and only supports CHS), while support for 48-bit LBA is optional. Thus, an operating system could decide to skip the 48-bit interface and use the 24-bit interface if the disk is smaller than a certain limit (8G).

SparrowOS · Post by **SparrowOS** » Mon Nov 19, 2012 4:20 pm

A typical drive is 1TB and you can save 5 uS if the access is to a block under 130Gig. I don't bother. When doing a compiler, you encounter the same thing and I often do bother.

SparrowOS · Post by **SparrowOS** » Mon Nov 19, 2012 4:24 pm

Tell me you code does this optimization and is not just old.

Brendan · Post by **Brendan** » Mon Nov 19, 2012 4:48 pm

Hi,

There are:

disks smaller than 528 MB
disks smaller than 8 GB that don't support LBA
disks smaller than 8 GB that do support LBA
disks larger than 8 GB
things that aren't hard drives (CD/DVD and SSD)

There are also 3 cases:

Software using the BIOS (e.g. an OSs boot code), where the BIOS doesn't support "int 0x13 extensions"
Software using the BIOS (e.g. an OSs boot code), where the BIOS does supports "int 0x13 extensions"
Software that doesn't use the BIOS (e.g. an OS's native driver)

5 possibilities multiplied by 3 possibilities = 15 permutations.

Now here's the important part: NONE OF YOU PEOPLE ARE SAYING WHICH CASES YOU'RE TALKING ABOUT.

Most of the statements made in this topic are true for some cases and false for other cases; and are therefore false when no specific case/s are specified.

Cheers,

Brendan

SparrowOS · Post by **SparrowOS** » Mon Nov 19, 2012 4:53 pm

http://en.wikipedia.org/wiki/Logical_block_addressing

28-bit LBA and 48-bit LBA.

It happens at 130GB

SparrowOS · Post by **SparrowOS** » Mon Nov 19, 2012 4:58 pm

You're right - not relevant for boot-loaders.

Int 13h 42 has a 64-bit block number

2^(28+9)=130GB

thepowersgang · Post by **thepowersgang** » Mon Nov 19, 2012 7:46 pm

I'm going to interject here (and possibly feed the troll) with what I am lead to believe is true about modern hard disks.

All modern disks internally (within the on-disk controller) use LBA, and perform remapping of known bad sectors automatically. They then provide almost completely false CHS dimensions to the BIOS so that legacy software can still access at least some of the disk. (Another thing to note is that any high-density disk doe not have the same number of sectors on every track, as the outer tracks are far longer than the inner tracks)

Yes, at the lowest levels, the disk needs to know what head to read from, what track to seek to, and how long to wait after the sync sector. However, these values are not known to the OS (and due to remapping and variable SPT values, can't be).

As for any (minor) speed changes due to either IO-port access speeds or calculations - I'd still say that CHS would be slower, as the drive (or controller) now has to convert the CHS address into the LBA address the drive expects.

SparrowOS · Post by **SparrowOS** » Mon Nov 19, 2012 8:11 pm

thepowersgang wrote:I'm going to interject here (and possibly feed the troll) with what I am lead to believe is true about modern hard disks.

All modern disks internally (within the on-disk controller) use LBA, and perform remapping of known bad sectors automatically. They then provide almost completely false CHS dimensions to the BIOS so that legacy software can still access at least some of the disk. (Another thing to note is that any high-density disk doe not have the same number of sectors on every track, as the outer tracks are far longer than the inner tracks)

Yes, at the lowest levels, the disk needs to know what head to read from, what track to seek to, and how long to wait after the sync sector. However, these values are not known to the OS (and due to remapping and variable SPT values, can't be).

As for any (minor) speed changes due to either IO-port access speeds or calculations - I'd still say that CHS would be slower, as the drive (or controller) now has to convert the CHS address into the LBA address the drive expects.

This whole discussion occurred because rdos said 28-bit was faster than 48-bit. That seemed to me as silly as saying CHS was faster than 28-bit. If you had a 1TB drive, who would use CHS even if it was faster? rdos is suggesting you only use the first 130Gig of a 1TB drive because he thinks the negligable port I/O time saved is worth it. In actual fact, he is a troll arguing for his own operating system that supports 28-bit and not 48-bit, being silly and dishonest.

OSDev.org