Re: HDD write cache
Investigating a bit more a device reset will also trigger the change so after changing the value you can use camcontrol reset to trigger the change to apply using e.g. camcontrol reset 0:0:0 THIS actually work. And the results are disastrous. in spite of NCQ working and fully filled, when unpacking source tree (as a test) onto UFS filesystem gstat shows at most 100 IOPS, and average 700 with write cache disabled. this is on / partition that spans 1/10 of disk. Drive can actually manage multiple writes in short distance well with write cache enabled. While this is stated in the man for ada its not obvious that changing the sysctl without a reset won't work, so you might want to raise a PR about it. Regards Steve - Original Message - From: "Steven Hartland" Looking at the cam ata code I can't see how those values would do anything after booting. I suspect they should be loader only tunables with the current code and cant be changed on the fly for a disk that's already been registered. Try setting the values in /boot/loader.conf if you haven't already? You can check the actual status of the disk itself using:- camcontrol identify ada0 Regards Steve - Original Message - From: "Wojciech Puchar" after reading quite recent topics about disabling/enabling write cache, i tried to test in on desktop 3.5" drive kern.cam.ada.write_cache: 1 kern.cam.ada.read_ahead: 1 kern.cam.ada.0.read_ahead: -1 kern.cam.ada.0.write_cache: -1 i tried writing 1 or 0 to kern.cam.ada.0.write_cache, and there were exactly no differences at all, and disk seems to do always write caching. Does that drive lie and ignore commands or i do it wrong? this is my disk. ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: HDD write cache
registered. Try setting the values in /boot/loader.conf if you haven't already? You can check the actual status of the disk itself using:- camcontrol identify ada0 this proved your statement. will check it out at next reboot. Regards Steve - Original Message - From: "Wojciech Puchar" To: Sent: Friday, February 01, 2013 2:26 PM Subject: HDD write cache after reading quite recent topics about disabling/enabling write cache, i tried to test in on desktop 3.5" drive kern.cam.ada.write_cache: 1 kern.cam.ada.read_ahead: 1 kern.cam.ada.0.read_ahead: -1 kern.cam.ada.0.write_cache: -1 i tried writing 1 or 0 to kern.cam.ada.0.write_cache, and there were exactly no differences at all, and disk seems to do always write caching. Does that drive lie and ignore commands or i do it wrong? this is my disk. ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ___ 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" This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: HDD write cache
Wojciech writes: > after reading quite recent topics about disabling/enabling write cache, i > tried to test in on desktop 3.5" drive > > kern.cam.ada.write_cache: 1 > kern.cam.ada.read_ahead: 1 > kern.cam.ada.0.read_ahead: -1 > kern.cam.ada.0.write_cache: -1 > > i tried writing 1 or 0 to kern.cam.ada.0.write_cache, and there were > exactly no differences at all, and disk seems to do always write caching. > > Does that drive lie and ignore commands or i do it wrong? > > this is my disk. > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ATA-8 SATA 2.x device > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) 1) See the other followups about making sure this change actually takes effect. 2) How, exactly, are you testing this? With Command Queueing enabled, (and assuming that it is working properly) you will not see any difference in speed with a casual test. Does ata(4) support your controller? Last time I looked, ata did not support NCQ. :-( So turning the write cache on/off gives a huge difference in speed. When ahci and siis came out, NCQ was so fast that it looked like the write cache was on. I had to write a special pathological test to be able to tell the difference between having the write cache on and using NCQ. I needed to verify that the write cache was really off so that my data was safe. In anything resembling normal use, NCQ with the write cache off is just as fast as having the write cache on. You really get the best of both worlds, speed and safety. Now all we need is NCQ support for all the controllers that have it. ___ 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: receiving aerial digital TV
[ This topic is better discussed in -multimedia@, suggest that followups drop -hackers@ ] > i am out of current knowledge about common TV for about 10 years. > > Currently in Poland there is aerial TV broadcasted in DVB-T standard. > There are TVs with builtin decoder/demodulator or separate > decoders/demodulator with HDMI output. > > But how about just receiving demodulated data and letting mplayer play it, > and - most importantly - recording it directly. I know there are USB > receivers on market. > > Are such devices supported under FreeBSD? if so - what driver, what > chipset to look when buying such a thing? any other recommendation. > > With analog TV broadcast there were PCI cards with brooktree chipset that > worked with FreeBSD. There are PCI and PCIe tuner cards, USB tuners, and Ethernet tuners. There used to be firewire tuners but these have disappeared the last time I looked. Each type has advantages and disadvantages. Cards require expansion slots, which you may or may not have available. Ethernet tuners allow locating the tuner near the antenna, giving less signal loss in the coax. And they don't need a slot, and are OS independent. Unfortunately, there seems to be only 1 brand of Ethernet tuner (Silicondust HDhomerun). The ATSC/8VSB version has better debugging info than other tuners, but there are many reports that other tuners give better reception. I don't know if this applies to the DVB-T version. Word is that some of the very small USB tuners suffer from poor reception. A high-gain "outdoor" antenna will give much better reception (due to less multipath) than a low gain antenna. Garbage in garbage out. If you manage to get a signal that is too strong, an attenuator is very inexpensive. Yes, you should be able to record to a file on disk and watch it later. Cron(8) and at(1) are useful for this. Some people like mythtv. Many of the cards use a cx88 family chip. cx88 (in ports) supports many of these cards. http://corona.homeunix.net/cx88wiki Ethernet tuners http://www.silicondust.com/ Useful forums for tuners, antennas, how to fix reception problems, ... http://www.avsforum.com/ Useful info about antennas and reception http://www.hdtvprimer.com ___ 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: HDD write cache
Investigating a bit more a device reset will also trigger the change so after changing the value you can use camcontrol reset to trigger the change to apply using e.g. camcontrol reset 0:0:0 While this is stated in the man for ada its not obvious that changing the sysctl without a reset won't work, so you might want to raise a PR about it. Regards Steve - Original Message - From: "Steven Hartland" Looking at the cam ata code I can't see how those values would do anything after booting. I suspect they should be loader only tunables with the current code and cant be changed on the fly for a disk that's already been registered. Try setting the values in /boot/loader.conf if you haven't already? You can check the actual status of the disk itself using:- camcontrol identify ada0 Regards Steve - Original Message - From: "Wojciech Puchar" after reading quite recent topics about disabling/enabling write cache, i tried to test in on desktop 3.5" drive kern.cam.ada.write_cache: 1 kern.cam.ada.read_ahead: 1 kern.cam.ada.0.read_ahead: -1 kern.cam.ada.0.write_cache: -1 i tried writing 1 or 0 to kern.cam.ada.0.write_cache, and there were exactly no differences at all, and disk seems to do always write caching. Does that drive lie and ignore commands or i do it wrong? this is my disk. ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: HDD write cache
Looking at the cam ata code I can't see how those values would do anything after booting. I suspect they should be loader only tunables with the current code and cant be changed on the fly for a disk that's already been registered. Try setting the values in /boot/loader.conf if you haven't already? You can check the actual status of the disk itself using:- camcontrol identify ada0 Regards Steve - Original Message - From: "Wojciech Puchar" To: Sent: Friday, February 01, 2013 2:26 PM Subject: HDD write cache after reading quite recent topics about disabling/enabling write cache, i tried to test in on desktop 3.5" drive kern.cam.ada.write_cache: 1 kern.cam.ada.read_ahead: 1 kern.cam.ada.0.read_ahead: -1 kern.cam.ada.0.write_cache: -1 i tried writing 1 or 0 to kern.cam.ada.0.write_cache, and there were exactly no differences at all, and disk seems to do always write caching. Does that drive lie and ignore commands or i do it wrong? this is my disk. ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ___ 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" This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: Testing SIOCADDMULTI?
On Friday, February 01, 2013 1:23:26 am Tim Kientzle wrote: > >> Would still appreciate any suggestions for how to test these. > > > > You can write a simple app to listen for UDP packets and have it join a > > multicast group and have another machine on the same network write a packet > > to > > the multicast group. > > I tried this first, but the test program worked fine even > without ADDMULTI/DELMULTI support. Watching > tcpdump -e, it appears that IP4 multicast UDP uses > broadcast at the Ethernet layer. Were you running tcpdump? You have to use tcpdump -p to avoid putting the chip into promiscuous mode if so (promiscious causes the NIC to receive all multicast regardless of the filters assuming that your driver supports it correctly). -- John Baldwin ___ 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"
HDD write cache
after reading quite recent topics about disabling/enabling write cache, i tried to test in on desktop 3.5" drive kern.cam.ada.write_cache: 1 kern.cam.ada.read_ahead: 1 kern.cam.ada.0.read_ahead: -1 kern.cam.ada.0.write_cache: -1 i tried writing 1 or 0 to kern.cam.ada.0.write_cache, and there were exactly no differences at all, and disk seems to do always write caching. Does that drive lie and ignore commands or i do it wrong? this is my disk. ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ___ 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: receiving aerial digital TV
On Friday 01 February 2013 13:46:59 Wojciech Puchar wrote: > i am out of current knowledge about common TV for about 10 years. > > Currently in Poland there is aerial TV broadcasted in DVB-T standard. > There are TVs with builtin decoder/demodulator or separate > decoders/demodulator with HDMI output. > > But how about just receiving demodulated data and letting mplayer play it, > and - most importantly - recording it directly. I know there are USB > receivers on market. > > Are such devices supported under FreeBSD? if so - what driver, what > chipset to look when buying such a thing? any other recommendation. > > With analog TV broadcast there were PCI cards with brooktree chipset that > worked with FreeBSD. > /usr/ports/multimedia/webcamd /usr/ports/multimedia/cx88 --HPS ___ 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: base gcc and _GLIBCXX_USE_C99
On 1 Feb 2013, at 13:31, Andriy Gapon wrote: > cstdlib would provide e.g. std::strtoull only when _GLIBCXX_USE_C99 is > defined. This is entirely consistent with the standard. strtoull() should only be visible when compiling in C++11 mode, it is not part of C++98 / C++03. David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: base gcc and _GLIBCXX_USE_C99
on 01/02/2013 15:08 Dimitry Andric said the following: > On 2013-02-01 14:01, Andriy Gapon wrote: >> on 28/01/2013 17:11 Andriy Gapon said the following: >>> I wonder why the following is the case for the base gcc. >>> /usr/include/c++/4.2/bits/c++config.h: >>> >>> /* Define if C99 functions or macros from , , , >>> , and can be used or exposed. */ >>> /* #undef _GLIBCXX_USE_C99 */ >>> >>> Because of this undef there is no e.g. std::strtoll(). >>> Ditto for other things in stdlib.h. > > Maybe this support can't be enabled, because we don't expose all the > required functions yet? Or maybe it is just something that was > committed years ago, and then forgotten. > > If we are sure that all the C99 functions libstdc++ requires are now > available and working, I see no problem in turning on _GLIBCXX_USE_C99. Having looked into the source code of a recent GCC I get an impression that this is a silliness on GCC's part (plus incompleteness of FreeBSD C99 support, it seems). cstdlib would provide e.g. std::strtoull only when _GLIBCXX_USE_C99 is defined. Now looking at libstdc++-v3/acinclude.m4 we can see that there is a dedicated check "for ISO C99 support in ". That check sets variable glibcxx_cv_c99_stdlib. But, _GLIBCXX_USE_C99 is set only if all of glibcxx_cv_c99_math, glibcxx_cv_c99_complex, glibcxx_cv_c99_stdio, glibcxx_cv_c99_stdlib and glibcxx_cv_c99_wchar are set. So if glibcxx_cv_c99_stdlib is yes, but something like glibcxx_cv_c99_complex is no, then no std::strtoull for me. Not sure why GCC couldn't have a dedicated macro "_GLIBCXX_USE_C99_STDLIB" like e.g. _GLIBCXX_USE_C99_MATH that it does have. -- Andriy Gapon ___ 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: base gcc and _GLIBCXX_USE_C99
On 2013-02-01 14:01, Andriy Gapon wrote: on 28/01/2013 17:11 Andriy Gapon said the following: I wonder why the following is the case for the base gcc. /usr/include/c++/4.2/bits/c++config.h: /* Define if C99 functions or macros from , , , , and can be used or exposed. */ /* #undef _GLIBCXX_USE_C99 */ Because of this undef there is no e.g. std::strtoll(). Ditto for other things in stdlib.h. Maybe this support can't be enabled, because we don't expose all the required functions yet? Or maybe it is just something that was committed years ago, and then forgotten. If we are sure that all the C99 functions libstdc++ requires are now available and working, I see no problem in turning on _GLIBCXX_USE_C99. ___ 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: base gcc and _GLIBCXX_USE_C99
[ping] on 28/01/2013 17:11 Andriy Gapon said the following: > > Guys, > > I wonder why the following is the case for the base gcc. > /usr/include/c++/4.2/bits/c++config.h: > > /* Define if C99 functions or macros from , , , >, and can be used or exposed. */ > /* #undef _GLIBCXX_USE_C99 */ > > Because of this undef there is no e.g. std::strtoll(). > Ditto for other things in stdlib.h. > -- Andriy Gapon ___ 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"
receiving aerial digital TV
i am out of current knowledge about common TV for about 10 years. Currently in Poland there is aerial TV broadcasted in DVB-T standard. There are TVs with builtin decoder/demodulator or separate decoders/demodulator with HDMI output. But how about just receiving demodulated data and letting mplayer play it, and - most importantly - recording it directly. I know there are USB receivers on market. Are such devices supported under FreeBSD? if so - what driver, what chipset to look when buying such a thing? any other recommendation. With analog TV broadcast there were PCI cards with brooktree chipset that worked with FreeBSD. Thank you very much ___ 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"
