On woensdag, nov 13, 2002, at 18:13 Europe/Brussels, Tyler Ward wrote: What does this tell us? Well first of all, there's no shortage of ram, so there's no reason why seti should be having many faults. The page faults are probably the cause of the context switches, and together they're probably the cause of much of the system time. I would guess it's simply reading data (doesn't seti use quite big datafiles?). Remember that a page is only 4kb and you said 49,000 were unaccounted for. That's about 2MB of data. Since dnetc is also getting a lot of context switches but no page faults, I don't think that's the problem. FWIW, the ktrace/kdump of dnetc shows: 471 dnetc CALL gettimeofday(0xf0080d20,0) 471 dnetc RET gettimeofday 1037184384/0x3dd22d80 471 dnetc CALL __sysctl(0xf0080d30,0x2,0xf0080d10,0xf0080d38,0,0) 471 dnetc RET __sysctl 0 471 dnetc CALL gettimeofday(0xf0080d10,0) 471 dnetc RET gettimeofday 1037184384/0x3dd22d80 471 dnetc CALL __sysctl(0xf0080d20,0x2,0xf0080d00,0xf0080d28,0,0) 471 dnetc RET __sysctl 0 ... I don't have a clue why it's calling that syscall so often though (then again, it already did that under 10.1.5 as well I guess, since I didn't upgrade the client since then). Jonas _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.