Hello, Alexander. You wrote 15 августа 2012 г., 15:07:32: AM> Yes, that is what I expected to see there. If you have timecounter other AM> then i8254, you can release i8254 from those duties to allow using it as AM> one-shot setting hint.attimer.0.timecounter=0. Otherwise there are no AM> options now.
% dmesg | grep timer pmtimer0 on isa0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: <AT timer> at port 0x40 on isa0 Event timer "i8254" frequency 1193182 Hz quality 100 % >> (a) with polling, system is responsive under any load, but wire2wifi >> performance is hugely affected by wire2wire traffic (and mpd5 >> inbetween). And, yes, "top" seems to lie about idle time. AM> I don't know why wifi is so different. Suppose it is for some reason AM> more affected by latencies. Adrian says, it is. >> (b) with interrupts, system works much better when it works (wire2wifi >> speed is affected by wire2wire traffic, but to much less extent), but >> it freezes every third minute for minute, when traffic is passed, but >> no user-level applications including BIND and DHCP server) works at >> all FOR MINUTE OR MORE. It not looks like 100ms lag, which could affect >> video playback. It looks like 60-120 seconds lag! At least, in case of >> ULE, I didn't try 4BSD yet. AM> In this case problem may be that kernel and interrupt threads are all AM> having absolute priorities. It means until they release the CPU, AM> user-level may get no CPU time at all. :( How could it be seen in KTR traces? Where could I read how to decipher and read these traces? -- // Black Lion AKA Lev Serebryakov <l...@freebsd.org> _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
