Re: FreeBSD for serious performance?
On 27/12/2012, at 13:44, Peter Jeremy pe...@rulingia.com wrote: I've only caught it hanging forever once. It only takes a few milliseconds to cause incoming data to be lost, I'm not sure what you mean by this. FreeBSD is not a real-time operating system and so offers no guarantees on how long it will take before incoming data will be processed. If you have an application that relies on incoming data being processed within milliseconds, you may need to do some redesign. In practise FreeBSD can actually do this (at least for moderate IO loads). At $work we use a USB interface to acquire ~10MB/sec from a data acquisition system which has a 96k FIFO (which is ~10 msec of buffering). We use 3ware RAID cards to write to disk on Supermicro boards though, you get what you pay for.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
Re: FreeBSD for serious performance?
If the driver is doing something daft like DELAY(x) in a fast interrupt handler which would lead to that behaviour, it should be fixed. If it's doing a DELAY(x) in a critical section, it shuld be fixed. They are doing *something* that completely locks out everything else. It is always a device driver. Now, it's quite likely you hit some kind of ata(4) bug which kept it in a tight loop Hard to imagine locking everything out for 19 minutes without being in a loop. So it was likely just spun in some high priority loop that nothing lower-priority could really do anything about. Would several different drivers have this same bug? The next time it happens, please break into the debugger and grab some debugging output. Show alllocks, ps, should be a good couple of things to start with. I've only caught it hanging forever once. It only takes a few milliseconds to cause incoming data to be lost, so I usually don't know about it until looking at the log file later. Not that I could jump into the debugger and gather data in a few milliseconds even if I knew when it was happening. BTW, how do I break into the debugger and gather data when all of the devices are locked out, including the console? I assume that once it recovers, there is no point in gathering data. Alternately - please find a currently actively maintained SATA chipset. The ata controller is soldered to the mainboard, a gazillion pins I'm sure, and no doubt requires very specialized equipment to replace, and I don't know of any pin-compatable replacements. Besides the hardware itself has never caused any problems. The problem is caused by the software, it is the software that needs to be fixed. Ata isn't maintained? Why the bleep not? Disk drivers are essential. I was under the impression that siis(4) and ahci(4) were actively maintained? I'm running four sata controllers using three different drivers and all three drivers lock out other drivers for too long when something unusual happens. And other, non-disk drivers have the same problem of locking out other drivers, even during normal operation. And this happens on yet other drivers on other people's hardware, not just mine. help migrate the nvidia chipset support out of ata(4) I've looked at several of FreeBSD's device drivers (including, as you might expect, ata, siis, and ahci) and I can't make heads or tails out of any of them. Back before FreeBSD existed, I did manage to make a significant improvement to a driver in a BSD-derived system, so I'm not a complete idiot. Several different drivers cause the same problem. Are they all making the same mistake? Or is there a problem in something they all use? Whether a design problem or an implementation bug. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance?
Hm, can you come up with a reproducable scenario where this happening? A lot of times the issues with disk drivers being upset is due to bad or incorrectly seated SATA cables. We're willing to help you out if you're willing to delve into the driver. Just ask questions about how it works and you'll likely get help :) Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance?
On 2012-Dec-25 21:51:14 -0500, Dieter BSD dieter...@engineer.com wrote: ata(4) completely hung the system for 19 minutes (at which point I manually intervened, see the PR), probably an infinite loop. http://www.freebsd.org/cgi/query-pr.cgi?pr=170675 Which contains no useful information. You've even edited out system details that are automatically inserted by send-pr. Please provide a dmesg from a verbose boot of that machine. What brand/model motherboard? What add-in cards do yau have? What do you mean by completely hung? What did you try to do to provoke a response? Are you running a GENERIC kernel? If not, please provide your kernel configuration. Please provide the SMART data for ad6 (smartctl -a /dev/ad6). Where does ad6 connect to the controller? Do you use any port-multipliers? What was the system doing when ad6 detached? Since the system ran for 24 hours, apparently without you noticing that ad6 had detached, is ad6 part of a RAID? If so, what is the RAID configuration and technology? Siis(4) and ahci(4) have also caused data loss, presumably by blocking interrupts for too long. You're still refusing to provide any useful information that might allow us to locate the supposed problem. Improving these drivers would be wonderful. But better yet, can we please find a way to fix the underlying problem? What underlying problem? When a device driver handles an interrupt, it needs to block further interrupts while it modifies its data structures. Otherwise another interrupt coming in might cause it to mangle the data. Right? But! Why does it need to block interrupts for everything? That depends on how the interrupts are laid out in the hardware. One popular approach on cheap motherboards is to have lots of different devices sharing the same interrupt. In this case, an interrupt generated by one device can block interrupts by all other devices sharing that interrupt. Alternately, why couldn't the data structures be protected with a mutex? Then the drivers shouldn't have to block even themselves. Alternately, why can't drivers have a polling option? Your patches implementing this functionality appear to have gotten detached from your mail. Could you please resend them. Note that several ethernet drivers already have a polling option (intended to avoid livelock issues at high traffic levels on primitive NICs). Current machines can have multiple disks, multiple Ethernets, multiple pretty-much-any-device, multiple CPUs, etc. etc. Which is why it's important to have complete details of the system when reporting issues since the problem may be caused by an unexpected interaction between the components. have this absurd bottleneck where the device drivers bring everything to a screaching halt every time an interrupt happens. So you keep claiming without producing any evidence. Can you please point to the code that does this. On 2012-Dec-26 03:48:04 -0500, Dieter BSD dieter...@engineer.com wrote: They are doing *something* that completely locks out everything else. It is always a device driver. So far, you have failed to provide any details to back this claim up. Hard to imagine locking everything out for 19 minutes without being in a loop. I can think of several possibilities: - broken controller locking up the bus - deadlock - clocks stopping (I've seen this in a different scenario) Would several different drivers have this same bug? You haven't provided any evidence of a software bug. If you're seeing the saem problem across lots of different devices, it suggests a hardware problem. I've only caught it hanging forever once. It only takes a few milliseconds to cause incoming data to be lost, I'm not sure what you mean by this. FreeBSD is not a real-time operating system and so offers no guarantees on how long it will take before incoming data will be processed. If you have an application that relies on incoming data being processed within milliseconds, you may need to do some redesign. BTW, how do I break into the debugger and gather data when all of the devices are locked out, including the console? Firewire? Have you verified that the console is locked up and you can't enter the debugger? The ata controller is soldered to the mainboard, a gazillion pins I'm sure, and no doubt requires very specialized equipment to replace, and I don't know of any pin-compatable replacements. Besides the hardware itself has never caused any problems. The problem is caused by the software, it is the software that needs to be fixed. The limited information you have provided points to a hardware fault, not a software bug. If you have evidence that it's a software bug, please provide it. Ata isn't maintained? Why the bleep not? Disk drivers are essential. ata(4) _is_ maintained. Your particular obsolete ATA controller may not be. I was under the impression that siis(4) and ahci(4) were actively maintained? I'm running four sata controllers using three different drivers and all
Re: FreeBSD for serious performance?
Which device drivers? We can't fix problems we don't know about. ata(4) completely hung the system for 19 minutes (at which point I manually intervened, see the PR), probably an infinite loop. http://www.freebsd.org/cgi/query-pr.cgi?pr=170675 Siis(4) and ahci(4) have also caused data loss, presumably by blocking interrupts for too long. Improving these drivers would be wonderful. But better yet, can we please find a way to fix the underlying problem? When a device driver handles an interrupt, it needs to block further interrupts while it modifies its data structures. Otherwise another interrupt coming in might cause it to mangle the data. Right? But! Why does it need to block interrupts for everything? Why does a disk driver need to block interrupts from Ethernet? Why does Ethernet need to block Firewire? Why does Firewire need to block USB? And so on. Can't the disk driver block just its own interrupts and leave the other devices alone? That way, when some device driver writer puts in DELAY(TOO_LONG), at least the other devices will still work. Alternately, why couldn't the data structures be protected with a mutex? Then the drivers shouldn't have to block even themselves. Alternately, why can't drivers have a polling option? Yes, the extra overhead of polling sucks, but losing incoming data sucks a lot more. I am not suggesting that polling should be the default, just an option for those who need it. Alternately, some method I haven't thought of Current machines can have multiple disks, multiple Ethernets, multiple pretty-much-any-device, multiple CPUs, etc. etc. We have SMP kernel to juggle those multiple CPUs. But we still have this absurd bottleneck where the device drivers bring everything to a screaching halt every time an interrupt happens. And if the driver has a bug, or thinks there is a problem and decides to keep DELAY()ing over and over, the entire machine just locks up and stays locked up, often forever. It isn't just me. I have seen quite a few threads where other people are having the same problem. This needs to be fixed. (Fixing this is at *least* a Usenix paper.) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance?
Hi, If the driver is doing something daft like DELAY(x) in a fast interrupt handler which would lead to that behaviour, it should be fixed. If it's doing a DELAY(x) in a critical section, it shuld be fixed. Otherwise, a DELAY(x) in a driver only chews CPU; the scheduler can preempt that. I don't agree with this behaviour, but it's possible. Now, it's quite likely you hit some kind of ata(4) bug which kept it in a tight loop without some kind of too many errors; bailing behaviour. I'm not an ata driver person; i have no idea why it's doing that. The driver shouldn't be disabling interrupts for other devices. That happens in critical sections and when doing lock operations. ata(4) doesn't call critical_* in the driver code. So it was likely just spun in some high priority loop that nothing lower-priority could really do anything about. The next time it happens, please break into the debugger and grab some debugging output. Show alllocks, ps, should be a good couple of things to start with. Alternately - please find a currently actively maintained SATA chipset. (Or Alternatively - step up and help migrate the nvidia chipset support out of ata(4).) Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance?
Am 12.12.2012 23:26, schrieb Wojciech Puchar: The cause of the low write performance is the disabled write cache. Enabling the write cache is unsafe on SATA drives (with or without NCQ), since they do not make any guarantees that nearby data is not lost if power fails during a disk write. It never happened to me, but there is a reason that SAS drives have less capacity, much lower BER (one to two magnitudes) and are more expensive than SATA drives. interface have nothing to do. Both allows you to force writes now and then. Yes and no. SATA drives could be built to the same standards as SAS drives, but with the exception of the WD Raptor they hardly ever are. SATA drives are optimized for storage density at low cost. SAS drives have completely different design targets, in general (or their higher price could not be satisfied). SATA drives have been reported to lie about the completion not only of normal writes, but also of flush commands. And with advanced format (4K sector) drives, data is at risk in (logical) sectors that are not even being written to. There is no technical reason that SATA drives are less reliable with regard to hardware (bit density, BER, ...) and firmware (less strict conformance testing compared to SAS drives), but there are market forces that have this effect. The solution to the performance problem is simple: Turn on the write cache. If the data is valuable, then SAS is the solution to both the If data is valuable, regular and well done backup practice is the only solution. I was referring to the higher quality firmware (with verified support for TCQ) of SAS drives. There were a number of consumer grade drives that supported tags, but where data was at risk due to firmware bugs. Backups are a way to recover from loss of data. Use of devices that are magnitudes more reliable improves short-term availability of the data and reduces the risk that a recovery will be needed. Don't mix immediate availability (as required by processing requirements) with availability of a recovery path. would pay one developer hour. Asking Nvidia to release the confidential documentation for their chip-set might help, but I doubt that there is much interest to add support for NCQ to an obsolete chip-set, today, unless you pay a developer (and even then ...). Even without this, i've never seen properly working NVidia hardware. ANY Yes, I've also had more problems with Nvidia hardware than with most other vendors' products. I guess this is due to the market segment they target (not sure whether this still applies for their expensive GPUs targeted at high performance computing). Regards, STefan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance?
There is no technical reason that SATA drives are less reliable with regard to hardware (bit density, BER, ...) and firmware (less strict conformance testing compared to SAS drives), but there are market forces that have this effect. The only sentence i could agree. But actually it is mostly propaganda to sell nearly same thing at 5x price. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance? (was: Re: 9.x -- New Install -- serious partition misalignment)
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? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance? (was: Re: 9.x -- New Install -- serious partition misalignment)
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. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance? (was: Re: 9.x -- New Install -- serious partition misalignment)
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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance? (was: Re: 9.x -- New Install -- serious partition misalignment)
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. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance?
So clock rate is the only thing that matters in your world? Yea, pretty much. operations per second do matter. compared to latest x86 hardware alpha lose even at the same clock speed. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance?
Am 11.12.2012 22:40, schrieb Adrian Chadd: I'm not seeing: * any references to driver code that exhibits that very broken behaviour; * any patches from you to implement NCQ on your nforce chipset; * any offer of incentive to any developer to add that support. Now, (1) is definitely worrying but as you've not provided any actual information, the level of helpfulness of this comment is 0. (2) and (3) would go a long way to making FreeBSD better. Yes, but the answer to (1) seems to be very simple: The cause of the low write performance is the disabled write cache. Enabling the write cache is unsafe on SATA drives (with or without NCQ), since they do not make any guarantees that nearby data is not lost if power fails during a disk write. It never happened to me, but there is a reason that SAS drives have less capacity, much lower BER (one to two magnitudes) and are more expensive than SATA drives. The solution to the performance problem is simple: Turn on the write cache. If the data is valuable, then SAS is the solution to both the performance and the inherent reliability problems. If SATA with NCQ really provides acceptable reliability, then a cheap SATA controller with NCQ support in FreeBSD might also be an option, at a cost that would pay one developer hour. Asking Nvidia to release the confidential documentation for their chip-set might help, but I doubt that there is much interest to add support for NCQ to an obsolete chip-set, today, unless you pay a developer (and even then ...). If all these don't work for you, then you may really be better served by Linux with the drivers donated by Nvidia. And if you buy a new system, you may consider choosing components from vendors that do not provide binary blobs for selected operating systems, but publish the necessary documentation for driver writers (or which develop open source drivers for FreeBSD, not only for Linux). There are so many ways to solve your problem ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance?
The cause of the low write performance is the disabled write cache. Enabling the write cache is unsafe on SATA drives (with or without NCQ), since they do not make any guarantees that nearby data is not lost if power fails during a disk write. It never happened to me, but there is a reason that SAS drives have less capacity, much lower BER (one to two magnitudes) and are more expensive than SATA drives. interface have nothing to do. Both allows you to force writes now and then. The solution to the performance problem is simple: Turn on the write cache. If the data is valuable, then SAS is the solution to both the If data is valuable, regular and well done backup practice is the only solution. would pay one developer hour. Asking Nvidia to release the confidential documentation for their chip-set might help, but I doubt that there is much interest to add support for NCQ to an obsolete chip-set, today, unless you pay a developer (and even then ...). Even without this, i've never seen properly working NVidia hardware. ANY ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance?
Ronald writes: 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 tha\ t. In short, Alphas hardly constitute high-end hardware in this day and age. So clock rate is the only thing that matters in your world? Yea, pretty much. As regards to reliability, except for the occasional low-level quirk (which is usually taken care of for me by the kernel guys) I've never had a processo\ r fail on me. Once, about five or six years ago I accidentally burnt up an Athlon XP (by not having the heatsink properly seated) but that was entirely my fault. I care about data integrity, so things like ECC are on my must-have list. I suspect that your cheap little media player thingy doesn't have ECC. If you don't care about getting the correct answer you can have infinite speed. A high clock rate doesn't help when some device driver does block_all_interrupts(); while(1) DELAY(MIGHT_AS_WELL_BE_FOREVER); At least four device drivers have caused me to lose data this way. Not what I call high performance. In my world, high-end means high quality. It doesn't necessarily mean fast, or recent. Data integrity, and yes, reliability, that sort of thing. Performance-wise, in most cases I don't expect to get 99.% of the theoretical best case, I'm usually happy with 90-95%. But without NCQ I'm only getting ~6% of what I should be getting. Pretty pathetic for an OS that claims to be all about performance. All the more so when the crappy OSes do support NCQ on that chip. It's not some rare, obscure chip. Lots of boxes have it. I never found a way to boot from different partitions, much less different disks with GPT. Having just been recently convinced to switch over to GPT (from MBR) I do most sincerly hope that you are either joking or mistaken about this. I am neither joking nor mistaken. I looked but could not find a way. I am not claiming that a way does not exist, merely that I couldn't find it. Perhaps there wasn't a way when I looked (it was awhile ago) but does exist now? I have never been a fan of MBRs, they are for pee-cees with the expected ugly kludges and limitations, real machines don't use them. GPT isn't perfect, but it seems much nicer than MBRs. Warren writes: Grub (or grub2) can do it. Back when I was triple-booting FreeBSD, NetBSD and Linux I used grub (rev number forgotten). It was supposed to be able to boot BSD from a partition but I never got that to work. I had to have it boot the MBR of a different disk which then booted BSD. I wrote 3 little shell scripts that edited grub's menu to change the default. So I could be running FreeBSD and type boot_netbsd, and go have lunch while it rebooted. Other than not booting BSD from a partition it wasn't that bad for something that smells of penguin. If you're booting multiple versions of FreeBSD, see gpart(8) for some partition attributes that may help. You mean the bootme bootonce stuff? That looks promising, assuming I can manage to decode the man page, and figure out what it actually does. Mostly multiple versions of FreeBSD. (for example 7.0 had a couple of bugs preventing it from booting, so having 6 still available was essential.) I no long need Linux (YEA!!!), and after a certain fubar incident have declared a Linux Free Zone. It would be nice if I could also boot Net/Open/Dragonfly. I don't see a way to boot multiple disks, but GPT allows enough partitions that I probably won't care. Not sure if the bootme bootonce stuff wasn't there yet when I looked, or if I just missed it. Thanks for the pointer. Or even consider ZFS boot environments. I plan to stick with FFS w/softdeps. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance?
I'm not seeing: * any references to driver code that exhibits that very broken behaviour; * any patches from you to implement NCQ on your nforce chipset; * any offer of incentive to any developer to add that support. Now, (1) is definitely worrying but as you've not provided any actual information, the level of helpfulness of this comment is 0. (2) and (3) would go a long way to making FreeBSD better. FreeBSD is only as much as the community of contributors and developers have the time and energy to make it be. If you want FreeBSD to be different/better/something, you have to step up. Adrian On 11 December 2012 12:43, Dieter BSD dieter...@engineer.com wrote: Ronald writes: 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 tha\ t. In short, Alphas hardly constitute high-end hardware in this day and age. So clock rate is the only thing that matters in your world? Yea, pretty much. As regards to reliability, except for the occasional low-level quirk (which is usually taken care of for me by the kernel guys) I've never had a processo\ r fail on me. Once, about five or six years ago I accidentally burnt up an Athlon XP (by not having the heatsink properly seated) but that was entirely my fault. I care about data integrity, so things like ECC are on my must-have list. I suspect that your cheap little media player thingy doesn't have ECC. If you don't care about getting the correct answer you can have infinite speed. A high clock rate doesn't help when some device driver does block_all_interrupts(); while(1) DELAY(MIGHT_AS_WELL_BE_FOREVER); At least four device drivers have caused me to lose data this way. Not what I call high performance. In my world, high-end means high quality. It doesn't necessarily mean fast, or recent. Data integrity, and yes, reliability, that sort of thing. Performance-wise, in most cases I don't expect to get 99.% of the theoretical best case, I'm usually happy with 90-95%. But without NCQ I'm only getting ~6% of what I should be getting. Pretty pathetic for an OS that claims to be all about performance. All the more so when the crappy OSes do support NCQ on that chip. It's not some rare, obscure chip. Lots of boxes have it. I never found a way to boot from different partitions, much less different disks with GPT. Having just been recently convinced to switch over to GPT (from MBR) I do most sincerly hope that you are either joking or mistaken about this. I am neither joking nor mistaken. I looked but could not find a way. I am not claiming that a way does not exist, merely that I couldn't find it. Perhaps there wasn't a way when I looked (it was awhile ago) but does exist now? I have never been a fan of MBRs, they are for pee-cees with the expected ugly kludges and limitations, real machines don't use them. GPT isn't perfect, but it seems much nicer than MBRs. Warren writes: Grub (or grub2) can do it. Back when I was triple-booting FreeBSD, NetBSD and Linux I used grub (rev number forgotten). It was supposed to be able to boot BSD from a partition but I never got that to work. I had to have it boot the MBR of a different disk which then booted BSD. I wrote 3 little shell scripts that edited grub's menu to change the default. So I could be running FreeBSD and type boot_netbsd, and go have lunch while it rebooted. Other than not booting BSD from a partition it wasn't that bad for something that smells of penguin. If you're booting multiple versions of FreeBSD, see gpart(8) for some partition attributes that may help. You mean the bootme bootonce stuff? That looks promising, assuming I can manage to decode the man page, and figure out what it actually does. Mostly multiple versions of FreeBSD. (for example 7.0 had a couple of bugs preventing it from booting, so having 6 still available was essential.) I no long need Linux (YEA!!!), and after a certain fubar incident have declared a Linux Free Zone. It would be nice if I could also boot Net/Open/Dragonfly. I don't see a way to boot multiple disks, but GPT allows enough partitions that I probably won't care. Not sure if the bootme bootonce stuff wasn't there yet when I looked, or if I just missed it. Thanks for the pointer. Or even consider ZFS boot environments. I plan to stick with FFS w/softdeps. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance?
On 2012-Dec-11 15:43:21 -0500, Dieter BSD dieter...@engineer.com wrote: I care about data integrity, so things like ECC are on my must-have list. Well, that's supported by all server CPUs (AMD Opteron, Intel Itanium, Intel Xeon, Oracle/Sun SPARC) and some desktop CPUs (most AMD x86 chips). A high clock rate doesn't help when some device driver does block_all_interrupts(); while(1) DELAY(MIGHT_AS_WELL_BE_FOREVER); At least four device drivers have caused me to lose data this way. Which device drivers? We can't fix problems we don't know about. Data integrity, and yes, reliability, that sort of thing. Virtually everything except some embedded and consumer-grade x86 systems manage that. But without NCQ I'm only getting ~6% of what I should be getting. So, in one sentence you state that ECC is a must have and then you complain that that FreeBSD doesn't support NCQ on an old, low-end (consumer-grade) chipset that doesn't support ECC. It's not some rare, obscure chip. Lots of boxes have it. None that support ECC, so you wouldn't be interested in any of them. I never found a way to boot from different partitions, much less different disks with GPT. Yes, this is a limitation of FreeBSD's GPT loader. So far, no-one has written the code to support multiple boot partitions or disks. Note that most BIOS's allow you to select the boot disk - which is a workaround. -- Peter Jeremy pgpgEyjjmIWvx.pgp Description: PGP signature
Re: FreeBSD for serious performance?
Ronald writes: 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. So clock rate is the only thing that matters in your world? In my world, high-end means high quality. It doesn't necessarily mean fast, or recent. Warren writes: A. Use ahci(4): The ada device driver takes full advantage of NCQ, when supported. Achi and siis support NCQ, but neither attach to the nforce4-ultra, which does support NCQ. I knew that NCQ would be required for acceptable performance and gave up other useful features to get it. Silly me, assuming that the performance orientated version of BSD would support such an essential performance feature on a very popular chipset. Linux has had NCQ on nforce4 since Oct 2006. Without NCQ, writes are slower than USB2, even with purely sequential writes (to the raw drive, no filesystem, so no seeking other then to the next track): device r/s w/s kr/s kw/s wait svc_t %b controller ad6 1726.5 0.0 217535.0 0.0 1 0.6 96 ata3-master ad6 0.0 109.5 0.0 13794.8 1 9.1 100 ata3-master da0 249.9 0.0 15741.4 0.0 1 6.0 100 umass-sim0 ad6 is ST3000DM001-9YN166 on nforce4-ultra chipset da0 is ST3000DM001-9YN166 USB3 disk on a USB2 port (from nforce) Sorry no write performance data for da0, I yanked the USB-to-SATA bridge off after doing some testing. The bridges they're currently shipping are slightly less crappy than they used to be, but they are still crap. 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. I never found a way to boot from different partitions, much less different disks with GPT. So I use NetBSD's MBR for disks I want to boot from. FreeBSD's and NetBSD's fdisk are both broken. Building MBRs by hand is such fun. Non-boot disks with multiple partitions use GPT. Big data disks get newfs-ed directly, no partitioning. The useless CHS baggage hangs around for decades, but useful hardware loses all support 5 nanoseconds after the last machine is sold. Other useful hardware waits years hoping to get support. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance?
Right, so the bug here is why isn't atacam attaching to the nforce4 ultra chipset. So this has changed from FreeBSD doesn't do NCQ to FreeBSD doesn't do NCQ on my particular desktop-aimed motherboard chipset. They're slightly different in scope, wouldn't you agree? Please file a PR and see if that can get resolved. I personally have no idea about the storage side of things so I don't know if it's a device id or whether there's something more complicated than that. Thanks, Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance?
Right, so the bug here is why isn't atacam attaching to the nforce4 ultra chipset. So this has changed from FreeBSD doesn't do NCQ to FreeBSD doesn't do NCQ on my particular desktop-aimed motherboard chipset. They're slightly different in scope, wouldn't you agree? Please file a PR and see if that can get resolved. I personally have no idea about the storage side of things so I don't know if it's a device id or whether there's something more complicated than that. Both the old and the new ata(4) have basic support for most of the older Nvidia chipsets, but lack some SATA-specific features like NCQ. Before AHCI was widely adopted, there were a variety of different interfaces on early SATA controllers. When Alexander and Scott were rewriting parts of the ATA and CAM code in FreeBSD, they had a limited amount of time and resources, so they concentrated on the newer ahci(4), mvs(4), and siis(4), not the many different interfaces of the earlier SATA controllers, although they invited people to add some of these on their own. The situation is also complicated by the fact that some of these earlier controllers had bugs, so even in Linux, where a larger number of the earlier controllers are more fully supported, some of the drivers disable NCQ and some other features by default, although the controllers are supposed to support them, e.g.: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=e2e031eb09760c36099ac127eeb175e06d257aef Of course, it is now possible to buy relatively inexpensive add-in SATA controller cards that are fully supported by one of the newer drivers and perform better than most of the old controllers. b. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance?
On Sun, 9 Dec 2012, Dieter BSD wrote: 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. I never found a way to boot from different partitions, much less different disks with GPT. Grub (or grub2) can do it. I haven't tried it because other operating systems I multiboot do not support GPT anyway. If you're booting multiple versions of FreeBSD, see gpart(8) for some partition attributes that may help. Or even consider ZFS boot environments.___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance?
In message 20121209091305.238...@gmx.com, Dieter BSD dieter...@engineer.com wrote: Ronald writes: 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. So clock rate is the only thing that matters in your world? Yea, pretty much. As regards to reliability, except for the occasional low-level quirk (which is usually taken care of for me by the kernel guys) I've never had a processor fail on me. Once, about five or six years ago I accidentally burnt up an Athlon XP (by not having the heatsink properly seated) but that was entirely my fault. I never found a way to boot from different partitions, much less different disks with GPT. Having just been recently convinced to switch over to GPT (from MBR) I do most sincerly hope that you are either joking or mistaken about this. The useless CHS baggage hangs around for decades, but useful hardware loses all support 5 nanoseconds after the last machine is sold. Other useful hardware waits years hoping to get support. Yeabut on the bright side, you can't beat the price! Regards, rfg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance?
.. the problem with Alpha is that there wasn't anyone who wanted to support it any longer. If someone wanted to stand up and resurrect it, support it, etc; I doubt the FreeBSD project would complain. The same thing is happening with ia64. Marcel still cares and he still does a lot of ia64 heavy lifting. Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance?
[ lack of SATA NCQ support for nforce4-ultra ]
Adrian writes:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=e2e031eb09760c36099ac127eeb175e06d257aef
which is:
The mcp61 has bug with ncq.
- { PCI_VDEVICE(NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA), SWNCQ },
- { PCI_VDEVICE(NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA2), SWNCQ },
- { PCI_VDEVICE(NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA3), SWNCQ },
+ { PCI_VDEVICE(NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA), GENERIC },
+ { PCI_VDEVICE(NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA2), GENERIC },
+ { PCI_VDEVICE(NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA3), GENERIC },
http://en.wikipedia.org/wiki/GeForce_6_Series
says: MCP61 introduced a bug in the SATA NCQ implementation.
As a result, Nvidia employees have contributed code to disable NCQ operations
under Linux.
I have not found a description of the bug.
But FreeBSD says I have:
nVidia nForce CK804 SATA300 controller port
0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xcc00-0xcc0f
mem 0xfebfb000-0xfebfbfff irq 21 at device 7.0 on pci0
nVidia nForce CK804 SATA300 controller port
0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xb800-0xb80f
mem 0xfebfa000-0xfebfafff irq 22 at device 8.0 on pci0
The CK804 (a few lines higher in the source file) did not get changed to
GENERIC.
As far as I can figure out, the bug (whatever it is) is limited to the MCP61.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance?
[ lack of SATA NCQ support for nforce4-ultra ]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=e2e031eb09760c36099ac127eeb175e06d257aef
which is:
The mcp61 has bug with ncq.
- { PCI_VDEVICE(NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA), SWNCQ },
- { PCI_VDEVICE(NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA2), SWNCQ },
- { PCI_VDEVICE(NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA3), SWNCQ },
+ { PCI_VDEVICE(NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA), GENERIC },
+ { PCI_VDEVICE(NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA2), GENERIC },
+ { PCI_VDEVICE(NVIDIA, PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA3), GENERIC },
http://en.wikipedia.org/wiki/GeForce_6_Series
says: MCP61 introduced a bug in the SATA NCQ implementation.
As a result, Nvidia employees have contributed code to disable NCQ operations
under Linux.
I have not found a description of the bug.
But FreeBSD says I have:
nVidia nForce CK804 SATA300 controller port
0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xcc00-0xcc0f
mem 0xfebfb000-0xfebfbfff irq 21 at device 7.0 on pci0
nVidia nForce CK804 SATA300 controller port
0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xb800-0xb80f
mem 0xfebfa000-0xfebfafff irq 22 at device 8.0 on pci0
The CK804 (a few lines higher in the source file) did not get changed to
GENERIC.
As far as I can figure out, the bug (whatever it is) is limited to the MCP61.
Sure, I wasn't suggesting that the bug affected your particular case
-- I was just mentioning the bug as an example that some of the older
SATA controllers have problems with useful features like MSI, power
management, port multiplication, or NCQ that the controllers are
supposed to support -- so that if anyone were considering creating a
FreeBSD driver for one of these controllers based on our existing
FreeBSD drivers, the product datasheets, and the Linux drivers at:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=drivers/ata;h=32325a5432d90c22dd1f19ee6c811af2145fc031;hb=HEAD
in order to get more than legacy mode support for the controller, then
they would be wise to look at the Linux drivers to see if the features
that they want actually work -- and weigh the investment of time and
effort against the alternative of buying a new storage card that works
well with one of our newer drivers.
b.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
FreeBSD for serious performance? (was: Re: 9.x -- New Install -- serious partition misalignment)
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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance? (was: Re: 9.x -- New Install -- serious partition misalignment)
In message 20121209014547.238...@gmx.com, Dieter BSD dieter...@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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance? (was: Re: 9.x -- New Install -- serious partition misalignment)
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 signature.asc Description: PGP signature
Re: FreeBSD for serious performance? (was: Re: 9.x -- New Install -- serious partition misalignment)
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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance? (was: Re: 9.x -- New Install -- serious partition misalignment)
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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance? (was: Re: 9.x -- New Install -- serious partition misalignment)
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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD for serious performance? (was: Re: 9.x -- New Install -- serious partition misalignment)
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. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
