[00:01:10] --- SecureEndpoints has left [00:13:12] --- SecureEndpoints has become available [02:15:42] --- haba has become available [03:14:14] --- sxw has become available [03:20:54] --- sxw has left [04:03:04] --- sxw has become available [04:06:07] --- sxw has left [04:58:49] --- mmeffie has become available [05:22:37] --- SecureEndpoints has left: Replaced by new connection [06:03:02] --- sxw has become available [07:10:55] --- sxw has left [07:11:34] --- SecureEndpoints has become available [07:12:38] --- sxw has become available [07:13:25] sometimes I am such an idiot. of course afsd_service.exe should be running at High priority. the system processes that handle all of the paging and i/o processing are at High priority. [07:13:44] seems smart to me. [08:14:56] --- reuteras has left [08:16:08] How many days should I wait before asking what happened to my reservation request to guesthouse@stanford.edu. ? [08:17:27] I phoned them in the end. Never got an email, but I have a reference number that I'm clinging to in the hope that it means I have a room. [08:17:47] I got an email [08:17:49] I used the web form 2009-03-30 11:36 (TZ=Paciffic) [08:18:24] I went through the web app, and got a confirmation email [08:19:30] Did you get anything in Subject: which could be useful for me in trying to find an email from them? [08:20:08] "Stanford Guest House Reservation #######" [08:20:18] where # means some digit [08:20:50] Hmm, I just tried the web form: "Database Not Open: Unable to process your request because the database "slacreg.fp5" is not open." [08:23:30] Spam points: 5.87 [08:23:38] Shit [08:25:00] abo: methinks there is some SPAM rule bending needed [08:49:20] Ok. Email from Stanford found. Pizza time. [08:49:37] summatusmentis: Thanks. [08:49:44] --- haba has left [08:49:56] doesn't even let me say 'your welcome' :-D [09:01:38] --- matt has become available [09:49:10] --- sxw has left [10:03:06] --- rra has become available [11:09:12] --- summatusmentis has left [11:42:17] --- dev-zero@jabber.org has become available [11:50:59] --- sxw has become available [11:58:10] --- dev-zero@jabber.org has left: offline [12:07:30] --- dragos.tatulea has become available [12:08:10] hi [12:08:20] hi [12:08:28] How's gsoc going along? [12:08:44] Currently unsure. [12:08:52] Things seem quiet this year, for everyone. [12:10:36] By everyone, u mean all orgs? [12:10:47] Yes [12:11:05] Now that is weird. [12:13:16] I think there's probably a number of factors. But yes, currently applications seem to be down across the board. [12:13:48] --- summatusmentis has become available [12:14:36] Factors such as? [12:15:52] --- sxw has left [12:43:01] --- mmeffie has left [12:46:13] SecureEndPoints - is your idiotness w. the afsd_service.exe priority something that's been around for a long time or new in 1.5.58? [12:51:42] dragos: Sorry, had to walk home. [12:52:06] Such as, the economic situation, the fact that the first week of SoC was during spring break in the US, the fact that the money hasn't increased in a while, ... [12:52:48] the economic situation should mean more people want the money, and they didn't have money to leave during break [12:52:58] imo [12:53:36] My theory is that they're going after work that pays more money, rather than doing SoC for the fun of it, because they've no idea if they'll have a job when they graduate. [12:54:58] --- abo has left [12:55:26] --- abo has become available [12:55:54] school is expensive :( more money helps in this situation [12:56:30] Life is expensive.... [12:56:35] life is expensive [12:56:37] good point [12:59:01] Debian is also seeing a huge drop-off in applicants, yeah. It does seem to be across the board. FreeBSD seems concerned as well. [12:59:36] Unless there's someone sitting quiet who has all the students, I don't think anyone's numbers have gone up this year. [12:59:37] email today said half as many applicants as registered students [12:59:54] Yeh, and there's less than 48 hours to go ... [13:00:00] presumably the same thing mentors saw yesterday [13:00:15] a lot of groups I've talked to are expecting a 'last minute rush' [13:00:17] Pretty much, yes. [13:01:50] The problem with a last minute rush is that it doesn't let orgs divert students away from oversubscribed ideas to undersubscribed ones. [13:02:12] well, clearly [13:02:23] not saying it's a good thing, just that it seems to be what people are expecting [13:02:29] the gsoc $$, though, is pretty decent for a summer job. [13:02:46] at least around here, very, very few students will find work that pays better. [13:02:57] I think it depends on location [13:03:02] i agree. i'd have killed for that. [13:03:03] * stevenjenkins nods. clearly. [13:03:16] even inflation adjusted back to what i would have had [13:03:17] I know csci students who will be making twice as much for an internship [13:04:00] for those that can get full-time summer, paid internships, sure, gsoc isn't such a great deal. [13:04:26] granted, and given the economic situation, less likely than previous years [13:04:31] however, the local Univs near me typically only get pretty lame internships..many are non-paid or pay only a pittance. [13:04:50] Of course, we should remember that one of Google's goals for this year was to increase the quality of the students, and reduce the midterm drop out rate. [13:04:51] even for csci? [13:05:06] summatusmentis - yes. [13:05:15] wow [13:05:30] local CS/IT work is pretty tough (which is why I telecommute) [13:06:27] wow [13:16:13] summatusmentis: I think another reason is that students are going to be much less likely to submit spurious applications, or to apply to multiple organisations, due to the now widespread requirements for patches. [13:16:32] widespread requirement for patches? [13:16:53] yes, that I agree with, with orgs putting more requirements into their templates, it will cut down on 'spam' apps [13:17:15] most minix hopefuls are porting applications to minix [13:18:42] RedBear: Following discussions at last year's mentors summit, most orgs now require students to build their code, and submit a patch for it, as part of their application process. [13:19:05] The idea is that it cuts down on students who aren't really interested, and who disappear as soon as the first payment is received. [13:19:17] interesting [13:21:44] I appreciate why they're doing that, but since it is the SUMMER of code... [13:22:38] I'm not sure I see your point? [13:22:52] it's not summer yet. no code [13:22:54] ah, you said "first payment" [13:23:06] they don't wait til the end to pay students, then [13:23:26] 2 payments [13:23:27] Students are paid in installments. The final installment is upon successful completion. [13:23:36] hmm [13:23:44] well, whatever [13:24:03] But, lots (I don't know hard figures, but lots) of students either disappear after the first payment, or are failed by their mentors because they haven't made enough progress. [13:24:32] which of course is solely the student's fault [13:25:24] Perhaps not entirely, but it does reduce the effectiveness of the program, whether you believe that its goal is writing software, or strengthening the open source community by adding new student developers to it. [13:25:57] sure [13:29:37] ... and the argument is that mentor (and admin) time is very valuable to the projects. If a mentor spends 60-70 hours with a student who disappears after the first payment, then the project's actually lost a lot of valuable time. And 60-70 hours is probably an underestimate of how long it takes from acceptance through to the midway point. [13:31:05] And there's also the fact that the Google folks did some extra effort to organize it this year... [13:31:59] shadow_gmailcom> 2 payments [13:32:02] technically 3 [13:32:30] 500 up front, for getting accepted [13:32:35] Indeed. [13:33:01] Although, I think most of the drop outs are after the 1st $2000, rather than after the $500. [13:33:09] right, that would be my guess [13:33:40] ... there are, of course, some people who are failed at the midterm too. But I think in previous years there was a tendency to give the benefit of the doubt. [13:53:07] --- dragos.tatulea has left [15:44:10] --- sxw has become available [15:44:16] --- sxw has left [15:54:16] no April Fools announcement from AFS? [15:54:28] like say, Microsoft is incorporating OpenAFS into Windows 7? [15:55:24] or is that actually a joke? >_> [15:55:51] AFS re-acquired by IBM? [16:11:51] 1.6 released today? [16:22:15] --- rra has left: Disconnected [16:25:28] --- Russ has become available [20:06:32] --- matt has left [20:42:59] RedBear: afsd_service.exe has never run at anything other than Normal priority [20:50:03] so, will bumping up its priority have a real effect... or will it just DOS the system (as can happen when one ups the priority of a process)? [20:51:11] in this case the system is already pushing the I/O requests through high priority processes. the fact that afsd_service.exe is normal priority means that requests back up in the kernel and don't get serviced [20:51:17] only 7 minutes left on the east coast... AFS is releasing its own OS [20:52:19] have you actually tried it? If so, what type of imprvements have you seen? [20:52:29] Write Performance (MB/sec): Encrypted Unencrypted 1.5.57 3.7 12.3 1.5.58+high 3.9 15.7 Uncached Read Performance (MB/sec): Encrypted Unencrypted 1.5.57 4.9 30.8 1.5.58+high 15.8 31.0 [20:53:06] interesting to note where a difference was and wasn't made [20:53:20] is that on a single large file or a bunch of small files? [20:53:43] I can't make the 1.4.5 file server send data any faster [20:54:09] 240MB file [20:54:40] I wonder if it helps at all for lots of small files [20:54:56] and I also wonder if this is an issue in other OSes [20:54:59] the primary benefit is under heavy load [20:55:14] the other OSs where the client is in the kernel? [20:55:24] there's still this afsd process, tho [20:55:47] but, I don't know what does what [20:55:48] its not the same [20:55:51] ok [20:56:25] re: heavy load... if I'm reading or writing 240MB of 500K files... that is still a heavy load [20:56:27] the problem I've been tracking with msft is under very heavy loads when the cpu is maxed out for hours at a time [20:56:36] um, not its not [20:56:41] ah, load as in cpu load [20:57:02] so, if I'm transferring a single 240MB file, I should see my cpu peak [20:57:16] as in everything. cpu, file i/o requests, network i/o requests, handle allocation, lock allocation, event signalling [20:58:13] k... I don't think I've ever see afs win put the cpu or the network under heavy load... can't speak about the others [20:58:36] its not afs putting the machine under load. its the apps [20:58:59] so you're saying if I'm doing something like running Photoshop out of afs [20:59:08] run 1000 web requests that load components out of afs [20:59:23] photoshop out of afs is nothing [20:59:35] pictage does that daily [20:59:36] photoshop kills machines regardless of where it's running :) [20:59:50] but it doesn't hammer the i/o subsystem [20:59:57] nor the network subsystem [21:00:27] it does seem to hammer the disk... tho unclear if that's i/o or virtual memory [21:00:42] think about the oafw model. application issues a file request in \\afs. that request goes to the kernel and is processed at high priority generating a network request which in theory is going to another box. [21:01:12] queue up several hundred requests to that supposedly other box [21:02:22] well... would be interesting to see if this reduces latency in "normal" usage [21:03:19] now turn it around and put that other box into a vm on the local machine. as the host OS gets stressed it continues to push out additional requests completely unaware that the local machine resources are necessary to process them. The more time is spent in the system services and kernel, less time is available to process the requests. Eventually they begin to time out [21:03:53] I've seen requests be received by afsd_service off the wire but not actually be given a timeslice by the cpu for 80 seconds [21:04:05] is that when I see smb timeout messages... or a different problem? [21:04:15] at least not enough time slice (due to the locks we obtain and drop) to actually fulfill the request [21:04:23] its part of that problem [21:05:26] fascinating [21:05:59] well... I'll look forward to trying this out whenever you release the change [21:07:44] it will be in 1.5.59 [21:07:51] cool [21:08:08] default will be High and it will be configurable [21:10:36] it will be released very soon [23:13:19] --- reuteras has become available [23:26:49] --- Russ has left: Disconnected