[12:42] <defendguin> BenC: do you know what the typical operating temperature of a intel dual core processor is?
[12:43] <BenC> defendguin: mine shows 44C
[12:43] <BenC> it's pretty idle though
[12:43] <defendguin> how many mhz?
[12:44] <defendguin> its clocking down to 1ghz or 800mhz?
[12:53] <defendguin> BenC: how should i record this?   i opened up this friend of mine's myspace page with about 50 slide shows and it gets the processor up half way and sends both cores to full speed and the fan begins to kick in and blow some air out of the side of the laptop and the temp gets up to about 71 degrees 
[12:53] <BenC> it's a 1.8Ghz
[12:53] <BenC> so it's probably clocking down to 1
[12:54] <BenC> defendguin: sounds like you can blame firefox...not sure if that's a bug
[12:54] <defendguin> i blame my friend
[12:54] <defendguin> the page is hideous 
[12:55] <JanC> IIRC those CPUs are safe up to 100 C or something?
[12:55] <defendguin> i have no idea
[12:56] <JanC> maybe not really good for CPU lifetime though  :)
[12:56] <defendguin> but it certainly seems like the fan is whirring and working properly
[01:00] <JanC> depends on where you measure too of course
[01:02] <defendguin> BenC: i guess this guy just has different hardware because the fan seems to be very responsive to the processor here.  Anywhere from silent at idle to noticeable when the processor was being used heavily 
[01:15] <defendguin> BenC: the guy pretty much gets the same results as me temp wise.   is 49C really too hot for a mostly idle processor?
[01:15] <BenC> not really
[01:17] <defendguin> i guess i could boot back into edgy and see if it is the same
[01:20] <defendguin> damn i guess i remove those options from grub :-(
[01:35] <defendguin> I am reading the technical specifications and typically they use a range of anywhere between 50 and 100C in these documents 
[01:39] <defendguin> any time they list anything below that the processor is in one of several sleep states
[01:51] <BenC> defendguin: sounds like a non-bug to me then
[01:54] <BenC> defendguin: I can get mine up to 75C doing a compile
[01:54] <BenC> then there's this:
[01:54] <BenC> critical (S5):           126 C
[01:55] <BenC> if critical trip point (instant power off) is 126C, then 70, even 80, doesn't sound so bad
[01:59] <Amaranth> 75C? damn, i get to 88C
[04:02] <panduwana> hello, i'm new, is there any tutorial about making kernel module for ubuntu?
[04:04] <BenC> panduwana: you really want #ubuntu
[04:04] <panduwana> oh ok sorry
[04:08] <Ivan_> probably an annoying questions by now, but ps3 wifi, how?
[04:17] <BenC> Ivan_: not
[04:17] <BenC> only ethernet is supported on ps3
[04:17] <BenC> otherwise use a USB wireless dongle supported by linux
[04:18] <mjg59> BenC: Hm. So, we're almost certainly going to want the code to forcible enable the HPET on ICH systems
[04:18] <mjg59> Which is, unfortunately, unlikely to make it in for .22
[04:18] <mjg59> But we should have what's approximately the final patch before then
[04:23] <BenC> mjg59: Ok
[04:26] <mjg59> So I don't think it's going to be a long term merge issue, but it may represent a divergence from upstream
[04:27] <mjg59> The issue is that the PIT has a minimum useful tick rate of around 40Hz, but there's the potential for us to get lower than that
[04:27] <mjg59> So HPET is useful, and most hardware from the past couple of years supports it. But BIOSes didn't start turning it on until fairly recently
[04:28] <mjg59> So it's a potentially very useful patch for power conservationm
[04:31] <BenC> Sounds useful, definitely give it a good once over
[04:32] <mjg59> Right. There's a possible suspend regression at the moment, which is why I'm not pushing it right now
[04:32] <mjg59> I'll see if I can find hardware to duplicate it on
[04:32] <mjg59> But then, I get the feeling that there may be regressions in that field in .22 in general right now, so...
[04:48] <BenC> mjg59: how big is the patch?
[04:48] <mjg59> Erm.
[04:48] <mjg59> Hang on a sec...
[04:49] <mjg59> 14K
[04:50] <Amaranth> lines or file size?
[04:50] <mjg59> File size
[04:50] <mjg59> 540 lines of diff (including context and headers)
[04:51] <mjg59> So not really /too/ bad
[04:51] <mjg59> It is, irritatingly, more of an hpet update rather than just the force-enabling
[04:51] <mjg59> But large parts of it are tied together
[04:57] <BenC> mjg59: any chance the hpet update gets into 2.6.22? :)
[04:57] <mjg59> Doesn't seem likely
[04:57] <mjg59> I've been talking to upstream about it
[09:10] <Edulix> hi
[09:11] <Edulix> I compiled my own ubuntu kernel, it was linux-source-2.6.22_2.6.22-2.7.tar.gz
[09:11] <Edulix> but it created 2.6.21 packages! how's that? wasn't it a 2.6.22? I'm confused
[03:04] <farion> can someone explain me, howto compile the source of linux-ubuntu-modules-2.6.22?
[03:13] <BenC> farion: sudo apt-get build-dep linux-ubuntu-modules-2.6.22; apt-get -b source linux-ubuntu-modules-2.6.22
[03:41] <farion> BenC: Okay, thx i'll try
[03:45] <ogra> BenC, i did the initramfs measurements -ltsp vs. -i386 ... -ltsp is finishing 11secs faster if i add a break=bottom ...
[03:46] <BenC> ogra: so from pxe finish to busybox is 11 seconds different?
[03:46] <ogra> yep
[03:46] <ogra> we take 55sec they 44
[03:46] <BenC> what about break=top?
[03:47] <ogra> i'll try with break top as well
[03:47] <ogra> hee beaten me
[03:47] <ogra> *heh
[03:47] <BenC> hehe
[03:47] <BenC> would be nice to know how much of that is initial kernel and how much is driver loading and initramfs scripts
[03:47] <ogra> yep
[03:48] <BenC> maybe take out the hibernate script in initramfs...you guys don't need that, right?
[03:48] <ogra> im not a big fan of stopwatching though ... 
[03:48] <BenC> hehe
[03:48] <ogra> right
[03:49] <Mithrandir> you should just install bootchart and work from that.
[03:50] <ogra> Mithrandir, well, jammcq refuses to use bootchart ... and on this 200Mhz client it takes nearly 1h to generate the final image ... 
[03:51] <ogra> to keep some consistency with the ltsp guis i resrted to use their "hit powerbutton and stopwatch" method for now
[03:51] <mjg59> 11 seconds seems like a fairly irrelevant difference when the complaint is an extra three minutes
[03:51] <ogra> *guys
[03:51] <ogra> yeah
[03:52] <ogra> it is
[03:52] <Mithrandir> ogra: just copying the tar.gz somewhere else and generating the image there should work fine.
[03:52] <ogra> sadly we have many of these 11 seconds in various places ... it stacks up
[03:55] <ogra> break top gives me 32secs for i386 and 23 sec for -ltsp
[03:56] <ogra> so their vmlinuz is already faster
[03:58] <maks_> well non-generic kernel
[03:58] <BenC> our vmlinuz should be pretty stripped down
[03:59] <BenC> what kernel is ltsp's?
[04:02] <zul> gah...I dislike it when things change
[04:04] <mjg59> ogra: That accounts for almost the entirity of the 11 seconds, so if you want to reduce it that's clearly what you should be looking at. However, it's still going to make almost no difference overall. 
[04:04] <ogra> yeah
[04:05] <ogra> i'm still trying to find the big switch i just need to flip to loose 2mins
[04:05] <mjg59> ogra: If you want to actually improve things, I think yo're going to have to figure out why stuff is actually slower. Did you do the NFS benchmarking with an ltsp kernel?
[04:05] <ogra> but it seems its just the stacked up amount of all these little things
[04:05] <ogra> yes, no big difference
[04:06] <ogra> one thing i assume will make a big difference is to use the ltsp initramfs script ... but thats to hackish that i even want to think about using it 
[04:06] <ogra> instead of a real nfsroot they use tmpfses and load all stuff into ram before going on with booting the real thing
[04:08] <ogra> so the actual bootsequence is done from ram ... not from the nfsroot
[04:09] <mjg59> So they transfer over a large file and then run from that?
[04:11] <ogra> the create tmpfses and move or bind mount particular nfs dirs into that
[04:11] <ogra> we do the same to gain rw access to crtain files on the readonly nfsroot ... but only in the booting system, not in the initramfs
[04:12] <BenC> well the initramfs is alreayd all in ram
[04:12] <mjg59> Right, but where are the binaries that they're actually executing?
[04:13] <BenC> doesn't read much from the nfsmount as far as I know
[04:13] <ogra> no, we just plainly mount / 
[04:13] <ogra> http://www.mcquillansystems.com/init.txt
[04:14] <ogra> thats their initramfs creator script
[04:15] <mjg59> ogra: That doesn't give a lot of insight
[04:15] <mjg59> But by the looks of it, the binaries they execute still come from the nfs mount, right?
[04:15] <ogra> right
[04:15] <mjg59> So I can't see why that would make any difference to startup times
[04:15] <ogra> ah, sorry, they dont bindmount, they link
[04:15] <mjg59> The only obvious difference is that their /tmp is on tmpfs
[04:16] <mjg59> Where does /tmp come from on the edubuntu systems?
[04:16] <ogra> ours as well, but later in the loop
[04:16] <ogra> from ltsp-client-setup, the firt initscript we run on ltsp clients
[04:16] <ogra> *first
[04:17] <ogra> which bind mounts various other stuff to ram as well
[04:17] <mjg59> Ok. So in that case, I can't see any reason why that would explain any speed differences
[04:17] <ogra> but only wih the writeabilty in mind, no speed thoughts involved
[04:18] <ogra> well, their stuff is earlier in ram than ours thats the only difference i see 
[04:19] <ogra> if you access anything the second ime you might be lucky to get it from ram instead of the nfsroot
[04:20] <mjg59> ?
[04:20] <mjg59> It doesn't execute anything from ram
[04:20] <ogra> if your /bin is on a ramdisk ? 
[04:20] <mjg59> It's not!
[04:21] <mjg59>  /bin is just a symlink into an NFS mount
[04:22] <ogra> hmm
[04:22] <ogra> right
[04:24] <ogra> you would have to copy it instead ... which would slow down even more ... weird ...
[04:24] <farion> howto do i recompile my ubuntu standardkernel - i only want to change two items?
[04:24] <ogra> i'm really runing out of ideas wher else to look
[04:25] <mjg59> farion: This isn't a support channel - #ubuntu is a better place to ask questions like that
[05:25] <lamont> 09:25:18.548890 IP 15.238.4.198.42014 > 10.0.0.2.80: S 4194244240:4194244240(0) win 5840 <mss 1460,sackOK,timestamp 93976 0,nop,wscale 5>
[05:25] <lamont> 09:25:18.549337 IP 10.0.0.2.80 > 15.238.4.198.42014: S 1534251669:1534251669(0) ack 4194244241 win 5792 <mss 1460,sackOK,timestamp 833213942 93976,nop,wscale 7>
[05:25] <lamont> 09:25:18.549382 IP 15.238.4.198.42014 > 10.0.0.2.80: . ack 1 win 183 <nop,nop,timestamp 93976 833213942>
[05:25] <lamont> so why do we pick a window size of 183??
[05:27] <lamont> and then why does the far side send 638 octets of data to that 183 window?
[06:12] <BenC> Anyone have any thoughts on enabling SLUB vs SLAB in gutsy?
[06:12] <BenC> I've been reading it, and it actually fixes some bugs, so I'm considering it for next upload
[06:14] <BenC> http://lwn.net/Articles/229096/ in case anyone wants to read up on it
[06:16] <lamont> any reason I can't run a gutsy kernel on a feisty box?
[06:16] <lamont> BenC: any chance you have a machine with the current top-of-tree kernel on it?
[06:16] <BenC> yeah
[06:17] <BenC> lamont: you can run gutsy kernel on feisty...I am
[06:17] <BenC> in fact, I'm running it on edgy in a few places too
[06:17] <lamont> could you capture the 3-way handshake for a wget of some random web page for me?
[06:17] <lamont> tcpdump, that is
[06:17] <lamont> BenC: rebuilt, or just drop the deb in and go?
[06:17] <BenC> if you can give me commands, I can do that
[06:17] <BenC> lamont: dpkg -i, and reboot
[06:18] <lamont> tcpdump -ni eth0 host 64.233.167.99
[06:18] <lamont> and in another window: wget 64.233.167.99
[06:18] <BenC> lamont: nvidia/fglrx support is a different story
[06:18] <lamont> then grab the first 3 lines of output
[06:18] <lamont> specifically, I'm looking at the number after 'win' :)
[06:18] <BenC> lamont:  does it matter than I'm behind a firewall?
[06:18] <lamont> 01:00.0 VGA compatible controller: nVidia Corporation NV25GL [Quadro4 900 XGL]  (rev a3)
[06:18] <lamont> no matter
[06:19] <lamont> so as long as it stll works, no 3d/etc is fine
[06:19] <BenC> yeah, it'll still work
[06:19] <BenC> 12:19:33.762854 IP 192.168.1.130.59038 > 64.233.167.99.80: S 2512816493:2512816493(0) win 5840 <mss 1460,sackOK,timestamp 36801128 0,nop,wscale 7>
[06:19] <BenC> 12:19:33.799159 IP 64.233.167.99.80 > 192.168.1.130.59038: S 2499560590:2499560590(0) ack 2512816494 win 8190 <mss 1460>
[06:19] <BenC> 12:19:33.799215 IP 192.168.1.130.59038 > 64.233.167.99.80: . ack 1 win 5840
[06:20] <BenC> this is stock 2.6.22-rc1
[06:20] <BenC> well, it's gutsy kernel, but it's stock
[06:20] <lamont> 10:20:43.051400 IP 15.238.4.198.44514 > 64.233.167.99.80: . ack 1 win 183 <nop,nop,timestamp 426415 23137170>
[06:20] <lamont> that's the feisty kernel
[06:21] <lamont> note the tcp receive window size of 183...
[06:21] <lamont> whatever fixed that bug would be good to get back into feisty
[06:21] <BenC> could be affected by sysctl stuff
[06:21] <lamont> 'twould make my coworkers happy
[06:21] <lamont> mine started with a window of 5840 as well
[06:22] <lamont> it just drops dramatically on the final ack
[06:22] <BenC> what win do you get back from remote?
[06:23] <BenC> win/scale stuff is weird
[06:23] <BenC> I've seen where certain windows machines work badly with linux when scaling is turned on
[06:23] <lamont> 65535 from google
[06:24] <lamont> can I force it to not scale?
[06:25] <lamont> 10:20:43.051551 IP 15.238.4.198.44514 > 64.233.167.99.80: P 1:102(101) ack 1 win 183 <nop,nop,timestamp 426415 23137170>
[06:25] <lamont> 10:20:43.136797 IP 64.233.167.99.80 > 15.238.4.198.44514: P 1:1431(1430) ack 102 win 65535 <nop,nop,timestamp 23137170 426415>
[06:26] <lamont> so does it violate RFC to send 1430 octets when the other end advertised a window of 183?
[06:33] <lamont> BenC: fixed in 2.6.22-1-server_2.6.22-1.5
[06:33] <BenC> lamont: there's a scaling setting in /proc/sys/ somewhere
[06:34] <lamont> thanks
[07:00] <lamont> BenC: hrm... actually, 2.6.22 shows the same issue, turning off window scaling makes it go away
[07:00] <lamont> --> bug in other vendor's stuff, not linux.  kthxbye
[07:00] <BenC> lamont: yeah, sounds about right
[07:08] <ogra> if i monitor an nfsroot thats mounted via udp with -o nolock with wireshark, why do i still see sunrpc noise over tcp ?
[08:05] <AnAnt> Hello, will there be a kernel fix for Feisty ?
[08:08] <zul> probably when it is ready
[08:09] <AnAnt> zul: do you know about that bug regarding MMC cards ?
[08:10] <Amaranth> you mean the broken tifm driver?
[08:10] <AnAnt> Amaranth: so it is broken ?
[08:11] <AnAnt> Amaranth: hello ?
[08:11] <Amaranth> yes
[08:11] <AnAnt> Amaranth: ic, no fix for it yet ?
[08:11] <Amaranth> you could use gutsy ;)
[08:12] <zul> its being worked on according to the bug reports
[08:12] <AnAnt> hmmm
[08:12] <AnAnt> zul: what is bug report # ?
[08:12] <zul> 53923 
[08:13] <AnAnt> zul: thanks
[12:15] <mjg59> BenC: Did you have a chance to check the appletouch thing?