FreeBSD for serious performance? (was: Re: 9.x -- New Install -- serious partition misalignment)

[Dieter BSD]

Ronald writes:
> This probably wouldn't be such a big deal if we were just talking about
> Linux.  But FreeBSD has always prided itself on being a serious OS for
> serious people with serious work to do... like major server farms and
> such.  In the context of high-end applications on high-end hardware where
> people are often trying to squeeze out that last drop of performance,

Linux is certainly a steaming pile of crap. BSD is orders of magnitude
better, but hey, that doesn't take much.

But don't brag about high-end hardware.  But FreeBSD has dropped support
for even semi-high-end hardware (DEC Alpha). So I'm stuck running it on
AMD64. Nothing against AMD, they did what they could to try and make a silk
purse (amd64) out of a sow's ear (x86). But even getting what passes for
a high quality board in amd64/x86 land with good reviews doesn't compare.
The firmware is absolute crap, and it's not like it is something you can
ignore. BTW, real high end hardware is redundant, better than mil-spec,
and provides better than 5-9s uptime. Been there, done that.

Several chips/features aren't supported properly. PRs sit for years on end.

> Performance has been degraded by a whopping 75% !

Having a 4KiB misalignment is nothing compared with not having NCQ
support. (Which even linux has, btw.) 25% performance would be a massive
upgrade. Or even worse, having the disk driver go into an infinite loop
with interrupts blocked, so *nothing* happens and all your incoming data
is lost until you manually intervene.

Speaking of alignment, I still get "partition 1 does not end on a
track boundary" messages. FreeBSD has no clue where the track boundaries
are and neither do I. Disks have used varying numbers of sectors/track
for longer than FreeBSD has existed.

This is your idea of serious?
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"

[Ronald F. Guilmette]

In message <2012120901...@gmx.com>,

"Dieter BSD" <diet...@engineer.com> wrote:

>But don't brag about high-end hardware.  But FreeBSD has dropped support
>for even semi-high-end hardware (DEC Alpha). So I'm stuck running it on
>AMD64. Nothing against AMD, they did what they could to try and make a silk
>purse (amd64) out of a sow's ear (x86). But even getting what passes for
>a high quality board in amd64/x86 land with good reviews doesn't compare.
>The firmware is absolute crap, and it's not like it is something you can
>ignore. BTW, real high end hardware is redundant, better than mil-spec,
>and provides better than 5-9s uptime. Been there, done that.
>
>Several chips/features aren't supported properly. PRs sit for years on end.
>
>> Performance has been degraded by a whopping 75% !
>
>Having a 4KiB misalignment is nothing compared with not having NCQ
>support. (Which even linux has, btw.) 25% performance would be a massive
>upgrade. Or even worse, having the disk driver go into an infinite loop
>with interrupts blocked, so *nothing* happens and all your incoming data
>is lost until you manually intervene.
>
>Speaking of alignment, I still get "partition 1 does not end on a
>track boundary" messages. FreeBSD has no clue where the track boundaries
>are and neither do I. Disks have used varying numbers of sectors/track
>for longer than FreeBSD has existed.
>
>This is your idea of serious?

In general, I agree with the point(s) you are making, but I do have a few
minor quibbles...

1) According to:

http://en.wikipedia.org/wiki/DEC_Alpha#Model_history

the last Alpha to be produced was shipped way back in 2004... eight years
ago... with a top speed of 1.3 GHz. I now have a cheap little media player
thingy sitting on my desk, and _each_ of its two cores runs faster than that.
In short, Alphas hardly constitute high-end hardware in this day and age.

2) Although I don't know a lot about boards, it is my understanding that
ASUS makes pretty good ones, and they have always worked for me (and the
firmware is typically quite good).


As regards to the Native Command Queuing.... all I can say is "Crap!"
I wasn't aware...until now... that FreeBSD did not support that. That
really is a rather entirely serious issue. But I do think that the
performance hit from that would be dwarfed by the performance hit that
could be caused by the AF misaligment problem.

And finally, yes, _nobody_ (except maybe the manufacturers) has known where
the actual physical track boundaries have been for a long long time now.


Regards,
rfg

[Alexander Kabaev]

On Sat, 08 Dec 2012 19:52:34 -0800
"Ronald F. Guilmette" <r...@tristatelogic.com> wrote:

"analysis" skipped.

>
> As regards to the Native Command Queuing.... all I can say is "Crap!"
> I wasn't aware...until now... that FreeBSD did not support that. That
> really is a rather entirely serious issue. But I do think that the
> performance hit from that would be dwarfed by the performance hit that
> could be caused by the AF misaligment problem.
>

ada0 at ahcich1 bus 0 scbus2 target 0 lun 0
ada0: <ST3750330AS SD1A> ATA-8 SATA 2.x device
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad0
ada1 at ahcich3 bus 0 scbus4 target 0 lun 0
ada1: <ST3750330AS SD1A> ATA-8 SATA 2.x device
ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C)

Crap! I must be dreaming then.

--
Alexander Kabaev

[Eitan Adler]

On 8 December 2012 23:04, Alexander Kabaev <kab...@gmail.com> wrote:
> On Sat, 08 Dec 2012 19:52:34 -0800
> "Ronald F. Guilmette" <r...@tristatelogic.com> wrote:
>
> "analysis" skipped.
>
>>
>> As regards to the Native Command Queuing.... all I can say is "Crap!"
>> I wasn't aware...until now... that FreeBSD did not support that. That
>> really is a rather entirely serious issue. But I do think that the
>> performance hit from that would be dwarfed by the performance hit that
>> could be caused by the AF misaligment problem.

From my memory, if you use ahci(4) instead of the old ata(4) you have
NCQ. If you still use ata(4), you don't.



--
Eitan Adler

[Adrian Chadd]

Hi,

Yes. atacam supports NCQ.

The older IDE/ATA code doesn't support NCQ. The CAM ATA code (ie,
atacam) supports it if the drive supports it.

So, the "FreeBSD doesn't do NCQ" point is incorrect.

If you don't believe me - look in sys/cam/ata/ata_da.c, look for ata_ncq_cmd().


Adrian

[Eitan Adler]

On 8 December 2012 23:19, Adrian Chadd <adr...@freebsd.org> wrote:
> Hi,
>
> Yes. atacam supports NCQ.
>
> The older IDE/ATA code doesn't support NCQ. The CAM ATA code (ie,
> atacam) supports it if the drive supports it.
>
> So, the "FreeBSD doesn't do NCQ" point is incorrect.
>
> If you don't believe me - look in sys/cam/ata/ata_da.c, look for ata_ncq_cmd().

Thanks for the correction - my memory was wrong.
--
Eitan Adler

[Warren Block]

On Sat, 8 Dec 2012, Dieter BSD wrote:

> Having a 4KiB misalignment is nothing compared with not having NCQ
> support.

...

> Speaking of alignment, I still get "partition 1 does not end on a
> track boundary" messages. FreeBSD has no clue where the track boundaries
> are and neither do I. Disks have used varying numbers of sectors/track
> for longer than FreeBSD has existed.

A. Use ahci(4):
"The ada device driver takes full advantage of NCQ, when supported."
Use 'camcontrol identify ada0' to check for NCQ support.

B. Use GPT, which does not have the CHS baggage. It is easier and more
versatile. My systems with GPT disks don't complain about track
alignment. Or maybe that's ahci(4)'s doing.

[Wojciech Puchar]

>> people are often trying to squeeze out that last drop of performance,
>
> Linux is certainly a steaming pile of crap. BSD is orders of magnitude
> better, but hey, that doesn't take much.

just pray FreeBSD will not incorporate too much "modern technologies" if
you know what i mean.

>
> But don't brag about high-end hardware.  But FreeBSD has dropped support
> for even semi-high-end hardware (DEC Alpha). So I'm stuck running it on

Because new ones no longer exist and new AMD64 hardware easily beats alpha
or SPARC hardware, with SPARC T3 being only serious competitor in total
throughput, but with enormous price and being in hands of oracle.

> AMD64. Nothing against AMD, they did what they could to try and make a silk

AMD64 is instruction set standard, made first by AMD but now all intels
have it too.

> a high quality board in amd64/x86 land with good reviews doesn't compare.

i would say that Dell servers are actually good in compatibility with
standards and performance. the "low end" (single socket xeon) ones are
cheap, others are not.

> The firmware is absolute crap, and it's not like it is something you can

true.

>
>> Performance has been degraded by a whopping 75% !
>

> Having a 4KiB misalignment is nothing compared with not having NCQ

4kB misalignment is HUGE performance loss.

> Speaking of alignment, I still get "partition 1 does not end on a

so why you create windows style slices at all? Why ada0s1a not just ada0a?

[Wojciech Puchar]

>
> 2) Although I don't know a lot about boards, it is my understanding that
> ASUS makes pretty good ones, and they have always worked for me (and the
> firmware is typically quite good).

maybe it's strange for for a long time i NEVER really succeeded making
stable configuration from popular parts. Yes it works fast, but when
running under heavy load with CPU quite loaded, lots of I/O from multiple
disks and over ethernet in the same time none are stable.
AHCI timeout is the most common message... or just random reboots.

Now getting low end Dell server (which isn't really low end) for not much
more money is what i do. it works.

[Wojciech Puchar]

what's a point of not using ahci(4)?

On Sat, 8 Dec 2012, Adrian Chadd wrote:

> Hi,
>
> Yes. atacam supports NCQ.
>
> The older IDE/ATA code doesn't support NCQ. The CAM ATA code (ie,
> atacam) supports it if the drive supports it.
>
> So, the "FreeBSD doesn't do NCQ" point is incorrect.
>
> If you don't believe me - look in sys/cam/ata/ata_da.c, look for ata_ncq_cmd().
>
>

> Adrian

[Wojciech Puchar]

> B. Use GPT, which does not have the CHS baggage. It is easier and more

bsd labels doesn't have too

> versatile. My systems with GPT disks don't complain about track
> alignment. Or maybe that's ahci(4)'s doing.