HI,misc:任何地方任何時間Free call - iphone apps下載致電回港免費
Having problems viewing this email? Please click here.For enquiry, please send email to i...@applecall4you.com eg!f3i1h.d;%d8 ge'e.9o h+ f f-$.ef d;;d=f %h)h+ i;i5h3 i...@applecall4you.com ef f(d8 f3e f6e0fegd?!d;6o h+ f ih#ie. Important Notice: Base on the Unsolicited Electronic Messages Ordinance, if you DO NOT want to receive any promotional email messages from us in the future, please kindly reply this e-mail for DELETION. If you would like to continue to receive our promotional email massages, you do not need to reply us.
Re: vmmap: bad software everywhere
On 2011-06-01 04.58, Damien Miller wrote: The recent trend of forking another process for a tab instead of a monolithic single process for the whole browser is a way of extending the time required to clean up this mess? Or there is no relation between them? I cannot look into the heads of the chrome devs. There's no technical reason why the tabs can't run in the same process. No technical reason if you exclude isolating mutually-distrusting data origins from each other. It is similar to the privilege separation we do in most OpenBSD network-facing daemons - it is pretty much the only way to do sandboxing on Unix. Yes, I was about to make that comment as well. Not only is there (perhaps) some security to be won that way, but also a more crash-resilient product. I often find myself having a couple of dozen browser windows, each with a dozen or more tabs, and whenever one of those 100+ sites does something that confuses the browser enough for it to crash, it brings down the whole house of cards with it. That is in fact the one advantage Chrome has that appeals to me - when it crashes it (most of the time) only brings down that one window/tab. (On the other hand, that it crashes in the first place is of course not a sign of a solid, secure, well made piece of software... oh well, that's modern software design for you.) Regards, /Benny -- internetlabbet.se / work: +46 8 551 124 80 / Words must Benny LC6fgren/ mobile: +46 70 718 11 90 / be weighed, / fax:+46 8 551 124 89/not counted. /email: benny -at- internetlabbet.se
Re: OT:Re: How do I exclude a directory using tar in OpenBSD?
On Tue, 31 May 2011 17:05:55 -0400, Eric Furman ericfur...@fastmail.net wrote: On Tue, 31 May 2011 13:43 +0200, Marian Hettwer m...@kernel32.de Obviously not. I'm talking about shell scripts which should work in a multi unix environment. Namely, in my env, Debian, Solaris and OpenBSD. I tend to install gnu sed and gnu grep and gnu diff on all 3 named systems. I actually see nothing bad about it. Not at all. And what do you do when you are not in charge of the box you need your script to run on? It is not uncommon to work in an environment with many thousands of boxes most of which you have no control over. You cannot depend on gnu or any other tools being installed on them. Better to have your script detect which OS it's running on and take appropriate action. You are establishing a very bad habit... I can only partly agree. In my case, I am in charge of them boxes. And we are talking a thousand and a bit. However, if I'm not in charge of the box, I do make sure that my script will run with the native tools of whatever unix (well, Linux, FreeBSD, OpenBSD, Solaris) it should run on. I do disagree with regards to a bad habit. It isn't. It's pragmatic. That's what you do if you are in charge of the boxes. And yep, this is really OT now. Cheers, Marian
Re: How do I exclude a directory using tar in OpenBSD?
On Tue, 31 May 2011 17:02:16 +0200, Otto Moerbeek o...@drijf.net wrote: $ pax -vw -f t.tar -x ustar -s /skip.this// . Should be portable... Good to know! I put this into my list of one-liners. Thanks! :) ./Marian
Re: vmmap: bad software everywhere
@ Corey clinge...@gmail.com wrote (2011-06-01 04:39+0200): I mean, come on -- storing data in unused bits in a pointer? Even I know that's a bad idea. But really, there are user-space memory pools which align on 8 or 16 byte boundaries, so here you have at least three perfectly fine bits. That's at least sometimes much much better than growing a structure by that very size for one bit or two. Super object. Washing machine. (Ooh - upper bounds are beyond my scope.) -- Ciao, Steffen sdaoden(*)(gmail.com) () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Re: vmmap: bad software everywhere
On Wed, Jun 01, 2011 at 01:48:03PM +0200, Steffen Daode Nurpmeso wrote: @ Corey clinge...@gmail.com wrote (2011-06-01 04:39+0200): I mean, come on -- storing data in unused bits in a pointer? Even I know that's a bad idea. But really, there are user-space memory pools which align on 8 or 16 byte boundaries, so here you have at least three perfectly fine bits. That's at least sometimes much much better than growing a structure by that very size for one bit or two. Super object. Washing machine. (Ooh - upper bounds are beyond my scope.) Storing tag bits in the lower bits of a pointer can be ok indeed if you know things about alignment restrictions. Using higher bits because they *seem* unused will bite you sooner or later. -Otto
Re: I don't get where the load comes from
On 2011-05-31 14.45, Artur Grabowski wrote: The load average is a decaying average of the number of processes in the runnable state or currently running on a cpu or in the process of being forked or that have spent less than a second in a sleep state with sleep priority lower than PZERO, which includes waiting for memory resources, disk I/O, filesystem locks and a bunch of other things. You could say it's a very vague estimate of how much work the cpu might need to be doing soon, maybe. Or it could be completely wrong because of sampling bias. It's not very important so it's not really critical for the system to do a good job guessing this number, so the system doesn't really try too hard. This number may tell you something useful, or it might be totally misleading. Or both. One thing that often bites me in the butt is that cron relies on the load average to decide if it should let batch(1) jobs run or not. The default is if cron sees a loadavg 1.5 it keeps the batch job enqueued until it drops below that value. As I often see much, much higher loads on my systems, invariably I find myself wondering why my batch jobs never finish, just to discover that they have yet to run. *duh* So whenever I remember to, on every new system I set up I configure a different load threshold value for cron. But I tend to forget, so... :-) I have no really good suggestion for how else cron should handle this, otherwise I would have submitted a patch ages ago... Regards, /Benny -- internetlabbet.se / work: +46 8 551 124 80 / Words must Benny Lvfgren/ mobile: +46 70 718 11 90 / be weighed, / fax:+46 8 551 124 89/not counted. /email: benny -at- internetlabbet.se
Re: I don't get where the load comes from
Load is generally a measure of a single processor core utilization over an kernel dependent time range. Generally as others have pointed out being a very broad (not as in meadow, as in continent). Different OS's report load very differently from each other today. Traditionally you would see a load average of 1-2 on a multicore system (I am talking HP-UX X client servers etc of the early 90's vintage). a Load average of 1 means a single core of the system is being utilized close to 100% of the time. On dual core systems a load average of 1 should be absolutely no cause for concern. Linux has moved away from reporting load average as a percentage of a single core time in recent days for precisely this reason, people see a load of 1 and think there systems are esploding. In the traditional mold todays processors should in theory get loads of 4-7 and still be responsive... On 31 May 2011 19:10, Joel Carnat j...@carnat.net wrote: Le 31 mai 2011 ` 08:10, Tony Abernethy a icrit : Joel Carnat wrote well, compared to my previous box, running NetBSD/xen, the same services and showing about 0.3-0.6 of load ; I thought a load of 1.21 was quite much. Different systems will agree on the spelling of the word load. That is about as much agreement as you can expect. Does the 0.3-0.6 really mean 30-60 percent loaded? As far as I understood the counters on my previous nbsd box, 0.3 meant that the cpu was used at 30% of it's total capacity. Then, looking at the sys/user counters, I'd see what kind of things the system was doing. 1.21 tasks seems kinda low for a multi-tasking system. ok :)
nat-to and route-to specified in a single rule
Hello, In a multi-homed setup I am trying to route out packets over the secondary interface on which also NAT is done. The environment consists of a OpenBSD 4.9 Firewall with 3 em interfaces, connected to 2 DSL providers em0: internal interface em1: first DSL em2: second DSL I did dome testing with the understanding ruleset, where I have specified a nat-to and route-to statement in a single rule ### rules ### pass in log on em0 from 192.168.1.118 nat-to (e2gress:0) route-to (em2 80.100.x.x) pass out log on em2 ### states ### all icmp 74.125.77.104:8 - 80.100.x.x:54000 (192.168.1.118:9035) 0:0 all icmp 80.100.x.x:54000 - 74.125.77.104:8 0:0 This setup somewhat works. When pinging an upstream host, the packets get send out over the secondary interface, but the first packet is always dropped! According to the pf.conf man page this rule specification is possible. My question is this kind of rule specification allowed and intended to be working in PF? When splitting the nat-to / route-to statement in the ruleset everything works fine. ### rules ### pass in log on em0 from 192.168.1.118 route-to (em2 80.100.x.x) pass out log on em2 from 192.168.1.118 nat-to (em2:0) ### states ### all icmp 74.125.77.104:8 - 192.168.1.118:8779 0:0 all icmp 80.100.x.x:9676 (192.168.1.118:8779) - 74.125.77.104:8 0:0 Regards Rob
Re: vmmap: bad software everywhere
On Tue, May 31, 2011 at 11:51 PM, bofh goodb...@gmail.com wrote: This is interesting. I would really appreciate it very much if you don't mind elaborating a bit more for a non-programmer? Thanks! The general idea which I believe is used by JS engines is to notice that javascript has two datatypes, floating point doubles and everything else (string, array, ...). A NaN is represented as the high 13 bits set to 1, meaning the bottom 51 can be used to store something else. Like a pointer to a string or array, plus some bits for type information and garbage collection. This makes your math code fast because it doesn't need to follow a pointer every time you add two numbers. It causes trouble because if you're lazy, you just assume all pointers (up to 64 bits) will fit in the limited space (maybe 44-48 bits), and then things break. Or you request the OS only give you low addresses (MAP_32BIT). Or you allocate a big block and manage it yourself, so you know all the pointers are close together. The technique is an old one. Usually, you'd store pointers, but reserve the low bit to mark integers. This has the effect of only giving you 31 bit integers. Javascript is based around doubles, so they did things in reverse and store doubles, but reserve special NaN patterns for pointers. I was first made aware of the NaN technique because it's used by luajit.
Re: I don't get where the load comes from
On 2011-06-01 15.12, Joel Wiramu Pauling wrote: Load is generally a measure of a single processor core utilization over an kernel dependent time range. No it isn't. You have totally misunderstood what the load average is. Generally as others have pointed out being a very broad (not as in meadow, as in continent). Different OS's report load very differently from each other today. That one's sort of correct, although I've yet to see an OS where the load doesn't in some way refer to an *average* *count* *of* *processes*. Traditionally you would see a load average of 1-2 on a multicore system (I am talking HP-UX X client servers etc of the early 90's vintage). a Load average of 1 means a single core of the system is being utilized close to 100% of the time. No, no, no. Absolutely *NOT*. It doesn't reflect CPU usage at all. And it never have. The load average must be the single most misunderstood kernel metric there have ever been in the history of unix systems. Very simplified it reflects the *number* *of* *processes* in a runnable state, averaged over some time. Not necessarily processes actually on core, mind you, but the number of processes *wanting* to run. Now, a process can be in a runnable state for a variety of reasons, and there is for example nothing that says it even needs to use up its alloted time slice when actually running, but it still counts as runnable. It can be runnable when waiting for a system resource; then it consumes *no* CPU cycles at all, but it still counts towards the load average. On dual core systems a load average of 1 should be absolutely no cause for concern. I routinely see load averages of 30-40-50, upwards of 100 on some of my systems. They run absolutely smooth and beautiful, with no noticable lag or delays. The processors may be near idling, they may be doing some work, it varies, but it is nothing I can tell from the load average alone. Linux has moved away from reporting load average as a percentage of a single core time in recent days for precisely this reason, people see a load of 1 and think there systems are esploding. In the traditional mold todays processors should in theory get loads of 4-7 and still be responsive... I'm sorry to say, but your entire text is based on a misunderstanding of what the load average really is, so the above sentences are totally irrelevant. Regards, /Benny On 31 May 2011 19:10, Joel Carnat j...@carnat.net wrote: Le 31 mai 2011 ` 08:10, Tony Abernethy a icrit : Joel Carnat wrote well, compared to my previous box, running NetBSD/xen, the same services and showing about 0.3-0.6 of load ; I thought a load of 1.21 was quite much. Different systems will agree on the spelling of the word load. That is about as much agreement as you can expect. Does the 0.3-0.6 really mean 30-60 percent loaded? As far as I understood the counters on my previous nbsd box, 0.3 meant that the cpu was used at 30% of it's total capacity. Then, looking at the sys/user counters, I'd see what kind of things the system was doing. 1.21 tasks seems kinda low for a multi-tasking system. ok :) -- internetlabbet.se / work: +46 8 551 124 80 / Words must Benny LC6fgren/ mobile: +46 70 718 11 90 / be weighed, / fax:+46 8 551 124 89/not counted. /email: benny -at- internetlabbet.se
Stands de alto impacto para Expos
Si el correo no se despliega correctamente da clic aqum Somos una empresa Mexicana, localizada en el Distrito Federal, queremos hacerles participe de los servicios que ofrecemos en XPOenlace.com Servicios XPOenlace S.A. de C.V. Diseqo y Fabricacisn de Stands Llama al 04455-5437-2658 o escribe a i...@xpoenlace.com Visita: www.XPOenlace.com Contacto: Fernando Fernandez 04455-5437-2658 i...@xpoenlace.com *** * Unsubscribe / Desinscribirse * *** Si usted ya no desea recibir esta informacisn favor de responder a este correo con el subject: REMOVER y sin ninguna otra accisn de su parte su direccisn de correo sera removida inmediatamente de nuestra lista de distribucisn.
Re: vmmap: bad software everywhere
On 1 June 2011 00:13, Theo de Raadt dera...@cvs.openbsd.org wrote: On Tue, May 31, 2011 at 10:39 PM, Corey clinge...@gmail.com wrote: data in unused bits in a pointer? Even I know that's a bad idea. Is it really that important to run your Javascript 2% faster? The difference is quite a bit more than 2%. The technique is sound, imo, but it seems the implementations are lacking some safeguards. The implementations are forcing OS developers to remove safeguards from our kernels. google MAP_32BIT Go see what linux and other systems do with the hint argument to mmap(), regarding address space randomization. Go read some of these implementations to see how often they pass a non-NULL hint. I'm so glad we have more performance in the most dangerous applications I wonder if the MAP_32BIT flag was pushed cause it broke apps, or if they were really concerned about the performance implication of having high addresses in amd64. Can't decide which is worst.
Re: I don't get where the load comes from
On 01-Jun-11 05:46, Benny Lofgren wrote: On 2011-05-31 14.45, Artur Grabowski wrote: The load average is a decaying average of the number of processes in the runnable state or currently running on a cpu or in the process of being forked or that have spent less than a second in a sleep state with sleep priority lower than PZERO, which includes waiting for memory resources, disk I/O, filesystem locks and a bunch of other things. You could say it's a very vague estimate of how much work the cpu might need to be doing soon, maybe. Or it could be completely wrong because of sampling bias. It's not very important so it's not really critical for the system to do a good job guessing this number, so the system doesn't really try too hard. This number may tell you something useful, or it might be totally misleading. Or both. One thing that often bites me in the butt is that cron relies on the load average to decide if it should let batch(1) jobs run or not. The default is if cron sees a loadavg 1.5 it keeps the batch job enqueued until it drops below that value. As I often see much, much higher loads on my systems, invariably I find myself wondering why my batch jobs never finish, just to discover that they have yet to run. *duh* So whenever I remember to, on every new system I set up I configure a different load threshold value for cron. But I tend to forget, so... :-) I have no really good suggestion for how else cron should handle this, otherwise I would have submitted a patch ages ago... I had tinkered with a solution for this: Cron wakes up a minute before the batch run is scheduled to run. Cron will then copy a random 4kb sector from the hard disk to RAM, then run either an MD5 or SHA hash against it. The whole process would be timed and if it completed within a a reasonable amount of time for the system then it would kick off a batch job This was the easiest way I thought of measuring the actual performance of the system at any given time since it measures the entire system and closely emulates actual work. While this isn't really the right thing to do, I found it to be the most effective on my systems.
Re: I don't get where the load comes from
On 1 June 2011 11:01, LeviaComm Networks n...@leviacomm.net wrote: On 01-Jun-11 05:46, Benny Lofgren wrote: On 2011-05-31 14.45, Artur Grabowski wrote: The load average is a decaying average of the number of processes in the runnable state or currently running on a cpu or in the process of being forked or that have spent less than a second in a sleep state with sleep priority lower than PZERO, which includes waiting for memory resources, disk I/O, filesystem locks and a bunch of other things. You could say it's a very vague estimate of how much work the cpu might need to be doing soon, maybe. Or it could be completely wrong because of sampling bias. It's not very important so it's not really critical for the system to do a good job guessing this number, so the system doesn't really try too hard. This number may tell you something useful, or it might be totally misleading. Or both. One thing that often bites me in the butt is that cron relies on the load average to decide if it should let batch(1) jobs run or not. The default is if cron sees a loadavg 1.5 it keeps the batch job enqueued until it drops below that value. As I often see much, much higher loads on my systems, invariably I find myself wondering why my batch jobs never finish, just to discover that they have yet to run. *duh* So whenever I remember to, on every new system I set up I configure a different load threshold value for cron. But I tend to forget, so... :-) I have no really good suggestion for how else cron should handle this, otherwise I would have submitted a patch ages ago... I had tinkered with a solution for this: Cron wakes up a minute before the batch run is scheduled to run. Cron will then copy a random 4kb sector from the hard disk to RAM, then run either an MD5 or SHA hash against it. The whole process would be timed and if it completed within a a reasonable amount of time for the system then it would kick off a batch job This was the easiest way I thought of measuring the actual performance of the system at any given time since it measures the entire system and closely emulates actual work. While this isn't really the right thing to do, I found it to be the most effective on my systems. You really think cron should be doing it's own calculation ? I don't like that *at all*. Can't we just have a higher default threshold for cron ? Can't we default to 0 ? I think this is something that should be looked up, if we admit load average is a shitty measure, we shouldn't rely on it for running cron jobs. I hereby vote for default to 0. (Thank god this isn't a democracy :-) )
Re: Obsolescence engineering (was: vmmap: bad software everywhere)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 01 Jun 2011 04:42:02 + annathemerm...@hush.com wrote: On 31 May 2011 19:51, Otto Moerbeek o...@drijf.net wrote: On Tue, May 31, 2011 at 07:23:46PM +, Christian Weisgerber wrote: Marc Espie es...@nerim.net wrote: Not surprisingly, a lot of software that claims to be 64 bits- ready isn't. This touches all web navigators, most jit engines, and probably lots more of software (our ports tree version of gnu-grep, for instance). I don't think a lot suffers from it, but some prominent cases do. Three problems have been mentioned: (1) Truncation of pointers to 32 bits. Our malloc(3) has returned addresses 4 GB for some time now on amd64 (and before that on other archs like alpha), so I don't expect any new fallout there. I seem to remember that we had a rash of ports fixes back when this first happened on amd64. (2) Tagged pointers. A tagged pointer is when you know that not all the bits in a pointer are used to generate an address and you squeeze some other data into the spare bits. This blocks newer versions of Firefox on sparc64. Mozilla's new JavaScript engine uses tagged pointers and those unused address bits on x86 are actually used on sparc64. (3) The expectation that, no matter what their absolute address, the relative offsets between all your pieces of data fit into 32 bits, i.e., all data is within a 4 GB window. That sounds like a bizarre requirement, but apparently some JIT engines are optimized to rely on this. These are the cases that break with new vmmap. The smart programmers solve number (3) by allocating 2G of memory in advance to store their jit compiled code, so their code can use 32 bit relative offsets. They say, hey, it's only virtual memory, so it doesn't take much resources. Often that is true and it seems a smart idea, but it has the consequence that you lose randomization and protected memory with page size granularity. Or you are forced to do all the memory mangement on your own, basically rewriting the memory management part of the OS in your browser. Suddenly the smart idea does not sound so smart anymore. -Otto But, hey, 64-bit desktop machines have only been around since 1993 or so, and I guess some of the Mozilla programmers weren't born yet when we watched oh-so-clever tagged pointer use blow up at, say, the Motorola 68000 to 68020 transition some 25 years ago. -- Christian naddy Weisgerber na...@mips.inka.de Great. Just absolutely fantastic. These people come up with more and more resource intensive ways of doing the same old computing tasks we've been able to do for a decade or more so that the rest of us have to buy newer, fancier, more expensive machines to do the same things we've been able to do for a decade or more. Of course, for a significant portion of the population, high performance computing means a computer I can access from the convenience of my home, rather than having to spend an hour walking to the library and an hour walking back just so I can sign up and wait an hour or two for the chance to use it for 30 minutes and then rush to do the important things, like fill out job applications for blue collar positions for companies who can't be bothered to take paper applications or check to see if I have any important business e-mail from people who are too annoying to send old-fashioned snail mail. For a lot of people, a computer is like a glorified communications device and typewriter. Except a whole lot more expensive. Hence the usefulness of old computers. When everyone else is rushing to get the latest and greatest, it's often possible to get a sufficiently aged computer for very cheap or even free. Of course, the big corporations don't make as much money if people do that. Which probably explains at least some of the bad software. If we make this new software resource intensive and inefficient enough, then people will have to buy newer, more expensive computers in order to run it. But the older software works just fine? Then we'll just have to stop releasing security patches for it. Good thing we didn't write solid, secure code to begin with. Now the hackers (or crackers, or whatever the correct term is) out there will force the laggards to upgrade to newer more expensive hardware than runs newer more expensive more inefficient software than we still support, and the computer industry goes on! Yay hackers! Well, I can understand that line from corporations looking to earn money, but it makes less sense to hear it from not-for-profits like Linux or Firefox. They say we should all upgrade our computers after three years, five years if we want to push it. What they seem to have missed is that it is a recession. A really bad recession. Goodbye art shows! Hello tent cities! Welcome to the most dangerous town in California: stop laying off cops! And that sort of thing In
Re: I don't get where the load comes from
On 2011-06-01 15.53, Joel Wiramu Pauling wrote: On 2 June 2011 01:41, Benny Lofgren bl-li...@lofgren.biz mailto:bl-li...@lofgren.biz wrote: I agree with what you are saying, and I worded this quite badly, the frame I was trying to setup was back in the day when multi-user meant something (VAX/PDP) - the load average WAS tied to core utilization - as you would queue a job, and it would go into the queue and there would be lots of stuff in the queue and the load average would bumo, because there wasn't much core to go around. Not wanting to turn this into a pissing contest, I still have to say that you are fundamentally wrong about this. I'm sorry, but what you are saying simply is not correct. I've worked in-depth on just about every unixlike architecture there is since I started out in this business back in 1983, and on every single one (that employed it at all) the load average concept has worked similarly to how I described it in my previous mail. (Not always EXACTLY alike, but the general principle have always been the same.) The reason I'm so adamant about this is that the interpretation of the load average metric truly is one of the longest-standing misconceptions about the finer points of unix system administration there is, and if this discussion thread can set just one individual straight about it then it is worth the extra mail bandwidth. :-) One only needs to look at all of the very confident, yet dead-wrong, answers to the OP:s question in this thread to realize that it is indeed a confusing subject. And the importance of getting it straightened out cannot be overstated. I've long ago lost count of the number of times I've been called in to fix a problem with high system loads only to find that the only metric used to determine that is... yes, the load average. I wonder how much money have been wasted over the years trying to throw hardware on what might not even have been a problem in the first place... Regards, /Benny That hasn't been the case for a very very long time and once we entered the age of multi-tasking load become unintuitive. Point being it's an indication of something today that isn't at all intuitive. Sorry for muddying the waters even more, my fuck up. On 31 May 2011 19:10, Joel Carnat j...@carnat.net mailto:j...@carnat.net wrote: Le 31 mai 2011 ` 08:10, Tony Abernethy a icrit : Joel Carnat wrote well, compared to my previous box, running NetBSD/xen, the same services and showing about 0.3-0.6 of load ; I thought a load of 1.21 was quite much. Different systems will agree on the spelling of the word load. That is about as much agreement as you can expect. Does the 0.3-0.6 really mean 30-60 percent loaded? As far as I understood the counters on my previous nbsd box, 0.3 meant that the cpu was used at 30% of it's total capacity. Then, looking at the sys/user counters, I'd see what kind of things the system was doing. 1.21 tasks seems kinda low for a multi-tasking system. ok :) -- internetlabbet.se http://internetlabbet.se / work: +46 8 551 124 80 / Words must Benny Lvfgren/ mobile: +46 70 718 11 90 / be weighed, / fax:+46 8 551 124 89/not counted. /email: benny -at- internetlabbet.se http://internetlabbet.se -- internetlabbet.se / work: +46 8 551 124 80 / Words must Benny Lvfgren/ mobile: +46 70 718 11 90 / be weighed, / fax:+46 8 551 124 89/not counted. /email: benny -at- internetlabbet.se
Re: I don't get where the load comes from
On 2011-06-01 17.16, Christiano F. Haesbaert wrote: On 1 June 2011 11:01, LeviaComm Networks n...@leviacomm.net wrote: On 01-Jun-11 05:46, Benny Lofgren wrote: On 2011-05-31 14.45, Artur Grabowski wrote: The load average is a decaying average of the number of processes in the runnable state or currently running on a cpu or in the process of being forked or that have spent less than a second in a sleep state with sleep priority lower than PZERO, which includes waiting for memory resources, disk I/O, filesystem locks and a bunch of other things. You could say it's a very vague estimate of how much work the cpu might need to be doing soon, maybe. Or it could be completely wrong because of sampling bias. It's not very important so it's not really critical for the system to do a good job guessing this number, so the system doesn't really try too hard. This number may tell you something useful, or it might be totally misleading. Or both. One thing that often bites me in the butt is that cron relies on the load average to decide if it should let batch(1) jobs run or not. The default is if cron sees a loadavg 1.5 it keeps the batch job enqueued until it drops below that value. As I often see much, much higher loads on my systems, invariably I find myself wondering why my batch jobs never finish, just to discover that they have yet to run. *duh* So whenever I remember to, on every new system I set up I configure a different load threshold value for cron. But I tend to forget, so... :-) I have no really good suggestion for how else cron should handle this, otherwise I would have submitted a patch ages ago... I had tinkered with a solution for this: Cron wakes up a minute before the batch run is scheduled to run. Cron will then copy a random 4kb sector from the hard disk to RAM, then run either an MD5 or SHA hash against it. The whole process would be timed and if it completed within a a reasonable amount of time for the system then it would kick off a batch job This was the easiest way I thought of measuring the actual performance of the system at any given time since it measures the entire system and closely emulates actual work. While this isn't really the right thing to do, I found it to be the most effective on my systems. You really think cron should be doing it's own calculation ? I don't like that *at all*. Can't we just have a higher default threshold for cron ? Can't we default to 0 ? I think this is something that should be looked up, if we admit load average is a shitty measure, we shouldn't rely on it for running cron jobs. I hereby vote for default to 0. (Thank god this isn't a democracy :-) ) I didn't really like Christophers suggestion either. For one thing, *any* kind of attempt at userland performance measurement will over time (as hardware gets faster) become less accurate to the point of not being usable unless tuned, and we really DON'T want to have to tune cron (or anything else userland for that matter) for different architectures and/or generations of systems. Also, what kind of metric should cron measure? What if the batch job is CPU-bound only, but will take two weeks to run and it's simply most convenient to start it using batch(1)? Or if the second batch job is i/o bound and doesn't get to run because I just started up the two-week CPU bound job and cron only measures that? In fact I really don't feel the load average is such a bad metric for cron to use, it's just that the default was probably set a millenia ago and hasn't changed since then. Easiest is to set the default to 0.0 as you suggest, disabling the feature altogether, more complicated but perhaps better in this world of multi-core systems might be to set it = number of cores. (Which also reminds me, sendmail have a similar feature using load average, which have also bugged me from time to time. Might be others as well, but none come to mind right now.) Regards, /Benny -- internetlabbet.se / work: +46 8 551 124 80 / Words must Benny Lvfgren/ mobile: +46 70 718 11 90 / be weighed, / fax:+46 8 551 124 89/not counted. /email: benny -at- internetlabbet.se
Re: vmmap: bad software everywhere
On Tue, May 31, 2011 at 12:51:27PM +0200, Marc Espie wrote: People not following development too closely may not be aware of it, but we've had a lot of fun with amd64 recently. Specifically, Ariane committed a new vmmap implementation that tends to actually use the 64 bits address space, in userland. She even has some more nasty diff that does its best to put allocations far apart in that address space. This sounds really cool. Thank you Ariane. Not surprisingly, a lot of software that claims to be 64 bits-ready isn't. This touches all web navigators, most jit engines, and probably lots more of software (our ports tree version of gnu-grep, for instance). If firefox or chrome can't fix their stuff in time what are our options for a graphical browser in the upcoming 5.0 release? To be honest I don't need anything fancy with javascript but just _some_ graphical browsers that displays pretty pictures would be nice. In that scenario can we find some old code and beef it up, or could we have our own openbsd web browser built from scratch? Not sure if it's OpenBSD's mission to include a browser but Google and Apple seem to think bundling a browser with their OS's is a must, even if they suck at it. I understand that we as a community have limited resources... and I don't think we should even think of reverting Arianes stuff nor put in that hack that Theo de Raadt asked us to google. Keep up the good work guys and gals, I'd help with coding but my X11 programming is very novice, let's see how time deals our cards eh? cut rest of quoted message Cheers, -peter
Re: I don't get where the load comes from
On 2011-06-01 15.53, Joel Wiramu Pauling wrote: On 2 June 2011 01:41, Benny Lofgren bl-li...@lofgren.biz mailto:bl-li...@lofgren.biz wrote: I agree with what you are saying, and I worded this quite badly, the frame I was trying to setup was back in the day when multi-user meant something (VAX/PDP) - the load average WAS tied to core utilization - as you would queue a job, and it would go into the queue and there would be lots of stuff in the queue and the load average would bumo, because there wasn't much core to go around. Not wanting to turn this into a pissing contest, I still have to say that you are fundamentally wrong about this. I'm sorry, but what you are saying simply is not correct. I've worked in-depth on just about every unixlike architecture there is since I started out in this business back in 1983, and on every single one (that employed it at all) the load average concept has worked similarly to how I described it in my previous mail. (Not always EXACTLY alike, but the general principle have always been the same.) The reason I'm so adamant about this is that the interpretation of the load average metric truly is one of the longest-standing misconceptions about the finer points of unix system administration there is, and if this discussion thread can set just one individual straight about it then it is worth the extra mail bandwidth. :-) 100% right. The load average calculation has not changed in 25 years. Anyone who says otherwise hasn't got a single fact on their side. What has changed, however, is that the kernel has more kernel threads running (for instance, ps aguxk, and look at the first few which have the 'K' flag set in the 'STAT' field. Some kernels have decided to not count those threads, others do count them. Since these kernel threads make various decisions for when to do their next tasks and how to context switch, the statistical monitoring of the system which ends up creating load values can get perturbed. That's what this comes down to.
Re: I don't get where the load comes from
On 01-Jun-11 08:39, Benny Lofgren wrote: On 2011-06-01 17.16, Christiano F. Haesbaert wrote: On 1 June 2011 11:01, LeviaComm Networksn...@leviacomm.net wrote: On 01-Jun-11 05:46, Benny Lofgren wrote: On 2011-05-31 14.45, Artur Grabowski wrote: The load average is a decaying average of the number of processes in the runnable state or currently running on a cpu or in the process of being forked or that have spent less than a second in a sleep state with sleep priority lower than PZERO, which includes waiting for memory resources, disk I/O, filesystem locks and a bunch of other things. You could say it's a very vague estimate of how much work the cpu might need to be doing soon, maybe. Or it could be completely wrong because of sampling bias. It's not very important so it's not really critical for the system to do a good job guessing this number, so the system doesn't really try too hard. This number may tell you something useful, or it might be totally misleading. Or both. One thing that often bites me in the butt is that cron relies on the load average to decide if it should let batch(1) jobs run or not. The default is if cron sees a loadavg 1.5 it keeps the batch job enqueued until it drops below that value. As I often see much, much higher loads on my systems, invariably I find myself wondering why my batch jobs never finish, just to discover that they have yet to run. *duh* So whenever I remember to, on every new system I set up I configure a different load threshold value for cron. But I tend to forget, so... :-) I have no really good suggestion for how else cron should handle this, otherwise I would have submitted a patch ages ago... I had tinkered with a solution for this: Cron wakes up a minute before the batch run is scheduled to run. Cron will then copy a random 4kb sector from the hard disk to RAM, then run either an MD5 or SHA hash against it. The whole process would be timed and if it completed within a a reasonable amount of time for the system then it would kick off a batch job This was the easiest way I thought of measuring the actual performance of the system at any given time since it measures the entire system and closely emulates actual work. While this isn't really the right thing to do, I found it to be the most effective on my systems. You really think cron should be doing it's own calculation ? I don't like that *at all*. Can't we just have a higher default threshold for cron ? Can't we default to 0 ? I think this is something that should be looked up, if we admit load average is a shitty measure, we shouldn't rely on it for running cron jobs. I hereby vote for default to 0. (Thank god this isn't a democracy :-) ) I didn't really like Christophers suggestion either. I don't like it either, but its only way to get my file server to run batch jobs without noticable performance loss For one thing, *any* kind of attempt at userland performance measurement will over time (as hardware gets faster) become less accurate to the point of not being usable unless tuned, and we really DON'T want to have to tune cron (or anything else userland for that matter) for different architectures and/or generations of systems. I never intended my suggestion to be used as-is in open-bsd proper, just as a mentioning of what I am doing to bypass bogus load values preventing my system from doing what it needs Also, what kind of metric should cron measure? What if the batch job is CPU-bound only, but will take two weeks to run and it's simply most convenient to start it using batch(1)? Or if the second batch job is i/o bound and doesn't get to run because I just started up the two-week CPU bound job and cron only measures that? The jobs I run on my file servers require a bit of everything In fact I really don't feel the load average is such a bad metric for cron to use, it's just that the default was probably set a millenia ago and hasn't changed since then. Easiest is to set the default to 0.0 as you suggest, disabling the feature altogether, more complicated but perhaps better in this world of multi-core systems might be to set it = number of cores. I agree with that, but I've had times where the load was genuinely high and the batch jobs cause the system to slow to the point of being unusable, or at least to the point where the users start complaining about it. (Which also reminds me, sendmail have a similar feature using load average, which have also bugged me from time to time. Might be others as well, but none come to mind right now.) Regards, /Benny -- -Christopher Ahrens
Battery monitoring does not work properly
Hello, I have seen the battery monitoring working properly after starting apmd however it just disappeared and I'm not able to make it work again, it results in Battery state: absent, 0% remaining, unknown life estimate Any idea how to make it properly work ? Thanks. OpenBSD 4.9 (GENERIC.MP) #794: Wed Mar 2 07:19:02 MST 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Genuine Intel(R) CPU T1400 @ 1.73GHz (GenuineIntel 686-class) 2.17 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM real mem = 3184750592 (3037MB) avail mem = 3122503680 (2977MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 05/22/09, BIOS32 rev. 0 @ 0xf0010, SMBIOS rev. 2.5 @ 0xfce70 (31 entries) bios0: vendor American Megatrends Inc. version 1.03 date 05/22/2009 bios0: ASRock Golden Series acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG ECDT DBGP BOOT OEMB HPET GSCI ATKG SSDT acpi0: wakeup devices USB0(S3) USB1(S3) USB2(S3) USB5(S3) EUSB(S3) USB3(S3) USB4(S3) USB6(S3) USBE(S3) HDAC(S3) P0P1(S4) GLAN(S4) P0P2(S3) WLAN(S3) P0P3(S3) P0P4(S3) P0P5(S3) P0P8(S4) P0P9(S3) SLPB(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 166MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Genuine Intel(R) CPU T1400 @ 1.73GHz (GenuineIntel 686-class) 2.17 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiec0 at acpi0 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P0P1) acpiprt2 at acpi0: bus 2 (P0P2) acpiprt3 at acpi0: bus 3 (P0P3) acpiprt4 at acpi0: bus 5 (P0P4) acpiprt5 at acpi0: bus 6 (P0P5) acpicpu0 at acpi0: C2, C1 acpicpu1 at acpi0: C2, C1 acpitz0 at acpi0: critical temperature 112 degC acpiac0 at acpi0: AC unit in unknown state acpibat0 at acpi0: BAT0 not present acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: LID_ acpivideo0 at acpi0: VGA_ acpivout0 at acpivideo0: DVID acpivout1 at acpivideo0: CRTD acpivout2 at acpivideo0: LCDD acpivout3 at acpivideo0: HDMI bios0: ROM list: 0xc/0x1! pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel GM45 Host rev 0x07 vga1 at pci0 dev 2 function 0 Intel GM45 Video rev 0x07 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1: apic 2 int 16 (irq 10) drm0 at inteldrm0 Intel GM45 Video rev 0x07 at pci0 dev 2 function 1 not configured uhci0 at pci0 dev 26 function 0 Intel 82801I USB rev 0x03: apic 2 int 16 (irq 10) uhci1 at pci0 dev 26 function 1 Intel 82801I USB rev 0x03: apic 2 int 21 (irq 7) uhci2 at pci0 dev 26 function 2 Intel 82801I USB rev 0x03: apic 2 int 19 (irq 3) ehci0 at pci0 dev 26 function 7 Intel 82801I USB rev 0x03: apic 2 int 18 (irq 6) usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 82801I HD Audio rev 0x03: apic 2 int 22 (irq 4) azalia0: codecs: Realtek ALC662, ATT/Lucent/0x1040, Intel/0x2802, using Realtek ALC662 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 82801I PCIE rev 0x03: apic 2 int 16 (irq 10) pci1 at ppb0 bus 1 re0 at pci1 dev 0 function 0 Realtek 8168 rev 0x03: RTL8168D/8111D (0x2800), apic 2 int 16 (irq 10), address 00:26:18:47:d2:f0 rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2 ppb1 at pci0 dev 28 function 1 Intel 82801I PCIE rev 0x03: apic 2 int 17 (irq 5) pci2 at ppb1 bus 2 athn0 at pci2 dev 0 function 0 Atheros AR9285 rev 0x01: apic 2 int 17 (irq 5) athn0: AR9285 rev 2 (1T1R), ROM rev 13, address 00:25:d3:0a:c8:a4 ppb2 at pci0 dev 28 function 2 Intel 82801I PCIE rev 0x03: apic 2 int 18 (irq 6) pci3 at ppb2 bus 3 ppb3 at pci0 dev 28 function 3 Intel 82801I PCIE rev 0x03: apic 2 int 19 (irq 3) pci4 at ppb3 bus 5 ppb4 at pci0 dev 28 function 4 Intel 82801I PCIE rev 0x03: apic 2 int 16 (irq 10) pci5 at ppb4 bus 6 ppb5 at pci0 dev 28 function 5 Intel 82801I PCIE rev 0x03 pci6 at ppb5 bus 7 uhci3 at pci0 dev 29 function 0 Intel 82801I USB rev 0x03: apic 2 int 23 (irq 10) uhci4 at pci0 dev 29 function 1 Intel 82801I USB rev 0x03: apic 2 int 19 (irq 3) uhci5 at pci0 dev 29 function 2 Intel 82801I USB rev 0x03: apic 2 int 18 (irq 6) ehci1 at pci0 dev 29 function 7 Intel 82801I USB rev 0x03: apic 2 int 23 (irq 10) usb1 at ehci1: USB revision 2.0 uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb6 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0x93 pci7 at ppb6 bus 8 pcib0 at pci0 dev 31 function 0
Re: Bad frame pointer crash again
On 05/25/11 09:05, Jeff Ross wrote:
On 05/24/11 01:52, Artur Grabowski wrote:
There is no such thing as a bad frame pointer crash. That's a
diagnostic message from ddb that it can't find anything further up the
stack trace, which is correct, since the function sched_sync is on top
of the stack.
Now, what the kernel tells you is that your kernel didn't panic, so
I'm not entirely sure how you end up in ddb, since there is no panic
or fault in the traceback. What does the traceback on other cpus show?
machine ddbcpu 0 will switch to cpu0, make a trace on each of them.
//art
Thanks, Art.
I was advised to try a current snapshot so if the server crashes again
with the same problem I will be sure to get the traceback from the rest
of the cpus.
Jeff
I just got dumped into ddb on this machine again--same basic message.
As suggested by Art above, I'm including the trace from each CPU,
followed by ps. I've now completely locked up the server (no response
from the console) so I can't get the most recent dmesg from the i386
snapshot I installed on May 25.
Thanks,
Jeff
ddb{1} show panic
the kernel did not panic
ddb{1} trace
handle_workitem_freeblocks(e02fde74,f0a0fa84,f05fbf2c,d03e1925) at
handle_worki
tem_freeblocks+0x2b
process_worklist_item(0,0,f05fbf5c,d03e1b8f,f05fbf44) at
process_worklist_item+
0x171
softdep_process_worklist(0,28,d08c6d1b,0,d03d2c83) at
softdep_process_worklist+
0x13f
sched_sync(daea73b8) at sched_sync+0xe5
Bad frame pointer: 0xd0baee88
ddb{1} ddb{1} machine ddbcpu 0
Stopped at Debugger+0x4: popl%ebp
ddb{0} trace
Debugger(d0af6100,30,f05afec4,296,d0af6134) at Debugger+0x4
i386_ipi_handler(b0,20,f05a,d0400010,d09c0010) at i386_ipi_handler+0x5f
Xintripi() at Xintripi+0x49
--- interrupt ---
__mp_lock(d0a39c24,d0a39c24,f05aff18,d0202630,0) at __mp_lock+0x55
i386_softintlock(0,d03e0020,d0a3,10,d0af0010) at i386_softintlock+0x12
Xintrltimer() at Xintrltimer+0x50
--- interrupt ---
cpu_idle_cycle(d0af6100) at cpu_idle_cycle+0xf
Bad frame pointer: 0xd0baee48
ddb{0} machine ddbcpu 1
Stopped at handle_workitem_freeblocks+0x2b:movl
0x10(%eax),%eax
ddb{1} trace
handle_workitem_freeblocks(e02fde74,f0a0fa84,f05fbf2c,d03e1925) at
handle_worki
tem_freeblocks+0x2b
process_worklist_item(0,0,f05fbf5c,d03e1b8f,f05fbf44) at
process_worklist_item+
0x171
softdep_process_worklist(0,28,d08c6d1b,0,d03d2c83) at
softdep_process_worklist+
0x13f
sched_sync(daea73b8) at sched_sync+0xe5
Bad frame pointer: 0xd0baee88
ddb{1} machine ddbcpu 2
Stopped at Debugger+0x4: popl%ebp
ddb{2} trace
Debugger(d4ec7c00,f05b1ec0,d03e4eb6,200296,d4ec7c34) at Debugger+0x4
i386_ipi_handler(b0,f05b0020,d03e,d0a30010,56630010) at
i386_ipi_handler+0x
5f
Xintripi() at Xintripi+0x49
--- interrupt ---
__mp_lock(d0a39c24,f05b1f18,f05b1f18,d0202630,0) at __mp_lock+0x52
i386_softintlock(0,d03e0020,d0a3,10,d4ec0010) at i386_softintlock+0x12
Xintrltimer() at Xintrltimer+0x50
--- interrupt ---
cpu_idle_cycle(d4ec7c00) at cpu_idle_cycle+0xf
Bad frame pointer: 0xd0baee48
ddb{2} machine ddbcpu 3
Stopped at Debugger+0x4: popl%ebp
ddb{3} trace
Debugger(d4ec7800,dfd31ec0,d03e4eb6,200296,d4ec7834) at Debugger+0x4
i386_ipi_handler(b0,dfd30020,d03e,d0a30010,b2640010) at
i386_ipi_handler+0x
5f
Xintripi() at Xintripi+0x49
--- interrupt ---
__mp_lock(d0a39c24,dfd31f18,dfd31f18,d0202630,0) at __mp_lock+0x52
i386_softintlock(0,d03e0020,d0a3,10,d4ec0010) at i386_softintlock+0x12
Xintrltimer() at Xintrltimer+0x50
--- interrupt ---
cpu_idle_cycle(d4ec7800) at cpu_idle_cycle+0xf
Bad frame pointer: 0xd0baee48
ddb{3} ps
PID PPID PGRPUID S FLAGS WAIT COMMAND
14144 15869 9572 0 3 0x280 nanosleep sleep
15869 9572 9572 0 3 0x280 pause sh
9572 6705 9572 0 3 0x280 pause sh
6705 7305 7305 0 3 0x280 piperdcron
29531 14027 29531503 3 0x288 poll postgres
12452 14027 12452503 3 0x288 selectpostgres
29034 14027 29034503 3 0x288 selectpostgres
15874 14027 15874503 3 0x288 selectpostgres
14027 20489 4672503 3 0x288 selectpostgres
23241 1 23241 0 3 0x280 ttyin getty
14849 1 14849 0 3 0x280 ttyin getty
14102 1 14102 0 3 0x280 ttyin getty
26245 1 26245 0 3 0x280 ttyin getty
13147 1 13147 0 3 0x280 ttyin getty
27251 1 27251 0 3 0x280 ttyin getty
23534 1 23534 0 3 0x280 poll wsmoused
7305 1 7305 0 3 0x280 selectcron
31278 1 31278 0 3 0x2080080 nanosleep sensorsd
14640 1 14640 62 3 0x280 bpf spamlogd
28612 29277 29277 62 3 0x280 piperdspamd
29823
Re: vmmap: bad software everywhere
On Wed, 1 Jun 2011 17:49:47 +0200 Peter J. Philipp wrote: Not sure if it's OpenBSD's mission to include a browser but Google and Apple seem to think bundling a browser with their OS's is a must, even if they suck at it. OSS - OpenBSD Secure Surfer or something - Would certainly make the headlines for 5. What a dream but I'm sure they've got more than enough on their plate, atleast for a while (hoping they won't have so much shit to deal with in the future). Can't see it in base ever either.
New dual core ARM Cortex-A9 board
http://www.origenboard.org/index.php?document_srl=130
Re: Relayd.conf -- Default closing of connection
Anybody?
What makes this even more confusing is that in the man page for
relayd.conf, it specifies a protocol called http_ssl that does NOT
have this directive:
http protocol http_ssl {
header append $REMOTE_ADDR to X-Forwarded-For
header append $SERVER_ADDR:$SERVER_PORT to
X-Forwarded-By
header change Keep-Alive to $TIMEOUT
query hash sessid
cookie hash sessid
path filter *command=* from /cgi-bin/index.cgi
ssl { sslv2, ciphers MEDIUM:HIGH }
}
The protocol in the default relayd.conf DOES, however:
http protocol httpssl {
header append $REMOTE_ADDR to X-Forwarded-For
header append $SERVER_ADDR:$SERVER_PORT to X-Forwarded-By
header change Connection to close
# Various TCP performance options
tcp { nodelay, sack, socket buffer 65536, backlog 128 }
# ssl { no sslv2, sslv3, tlsv1, ciphers HIGH }
# ssl session cache disable
}
I'm just after an explanation of what closing the connection is
attempting to accomplish, and why it seems to be arbitrarily inserted
into the default relayd.conf.
Thanks,
Andrew Klettke
Systems Admin
Optic Fusion NOC
253-830-2943
On 05/31/2011 10:34 AM, Andrew Klettke wrote:
Hello,
In the default relayd.conf, we have, in the httpssl protocol, the
directive `header change Connection to close`.
What about relayd makes this desirable (why close connections when we
can reuse them or let them time out?), and what are the consequences
of NOT having this directive?
Re: vmmap: bad software everywhere
Ariane van der Steldt wrote: On Tue, May 31, 2011 at 03:28:11PM -0500, Amit Kulkarni wrote: basically rewriting the memory management part of the OS in your browser. Do some browsers do this on OpenBSD? Googles v8 javascript engine has Pages, Spaces, Heaps and Pagination logic. It even has its own code to map files in. However, the managed to avoid the common pitfall of requiring all platforms to have 4 kB pages: they hardcoded to 8 kB instead. They actually managed to create their own VM inside the browser, running on top of our VM and being almost as complex. Chrome are the ones that use 32-bit relative pointers, I doubt I need to explain how that fails on 64-bit... But hey, it's fast. Webkit allocates 2 GB at startup. Within that area, it will do its own memory management for the JIT. They also use 32-bit relative addressing. Firefox uses the unused bits in your pointer to store some tags there. Because on 64-bit computers we have all these bits, but only 48 are used. So we can store 16 bit worth of data, for free! Ofcourse, your address randomization will be friendly enough to pick memory close to the base of your memory, so of those 48 bits, only 34 are really in use... Why do they need such a trick instead of simply storing tags in a associative array, where key is a pointer and value is a set of tags (or any other arbitrary data)? Lookup against properly aligned array is relatively fast. Am I missing something? Alexey
Re: IBM xServer 336/346 - OpenBSD 4.9
Daniel, What i did to make my x336 servers work with OpenBSD 4.9 was to replace pci.c from the source with pci.c 1.72 . Is this somehow wrong? Should i apply this patch instead? Regards, Marcos LEVAI Daniel wrote: Hi! (Just for the record) Regarding PR#6523, OpenBSD 4.9 works with pci.c 1.88 (from OPENBSD_4_9), patched with kettenis@'s pci.c patch 1.72 [1]. I was afraid it won't apply, or there will be incompatibilities with other parts, but so far so good. (It's unfortuane it broke other systems :( ) Anyway, thanks! [1]: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/pci.c.diff?r1=1.71;r2=1.72 Daniel
Re: I don't get where the load comes from
On 1 June 2011 17:49, Theo de Raadt dera...@cvs.openbsd.org wrote: What has changed, however, is that the kernel has more kernel threads running (for instance, ps aguxk, and look at the first few which have the 'K' flag set in the 'STAT' field. In ps aguxk, what does the g do? I didn't find enlightenment on the man page or the Googles. -- PS: Apologies btw. for not responding to and thanking list members who wrote helpful replies after my graphics tablet question. That's one's kinda slipped through and I meant to get back to it, but...
Re: vmmap: bad software everywhere
@ Otto Moerbeek o...@drijf.net wrote (2011-06-01 14:12+0200): Storing tag bits in the lower bits of a pointer can be ok indeed if you know things about alignment restrictions. Of course it all stands and falls with the quality of the memory allocator! If that sucks your canary's chirp beeps like a mouse in a huge arena! So no - no randomness here. And beside that it tends to get inscrutable when accessing the bits, even if one uses unions to avoid casts. -- Ciao, Steffen sdaoden(*)(gmail.com) () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Re: I don't get where the load comes from
On Wed, Jun 01, 2011 at 09:49:17AM -0600, Theo de Raadt wrote: On 2011-06-01 15.53, Joel Wiramu Pauling wrote: On 2 June 2011 01:41, Benny Lofgren bl-li...@lofgren.biz mailto:bl-li...@lofgren.biz wrote: I agree with what you are saying, and I worded this quite badly, the frame I was trying to setup was back in the day when multi-user meant something (VAX/PDP) - the load average WAS tied to core utilization - as you would queue a job, and it would go into the queue and there would be lots of stuff in the queue and the load average would bumo, because there wasn't much core to go around. Not wanting to turn this into a pissing contest, I still have to say that you are fundamentally wrong about this. I'm sorry, but what you are saying simply is not correct. I've worked in-depth on just about every unixlike architecture there is since I started out in this business back in 1983, and on every single one (that employed it at all) the load average concept has worked similarly to how I described it in my previous mail. (Not always EXACTLY alike, but the general principle have always been the same.) The reason I'm so adamant about this is that the interpretation of the load average metric truly is one of the longest-standing misconceptions about the finer points of unix system administration there is, and if this discussion thread can set just one individual straight about it then it is worth the extra mail bandwidth. :-) 100% right. The load average calculation has not changed in 25 years. Anyone who says otherwise hasn't got a single fact on their side. The metric was invented in a time when processes were swapped in and out routinely. This is why load, nice and the scheduler all behave the way they do (which to our modern minds seem strange and arcane). What has changed, however, is that the kernel has more kernel threads running (for instance, ps aguxk, and look at the first few which have the 'K' flag set in the 'STAT' field. Some kernels have decided to not count those threads, others do count them. Since these kernel threads make various decisions for when to do their next tasks and how to context switch, the statistical monitoring of the system which ends up creating load values can get perturbed. That's what this comes down to. -- Ariane
Re: I don't get where the load comes from
On Wed, Jun 01, 2011 at 11:09:03PM +0200, ropers wrote: On 1 June 2011 17:49, Theo de Raadt dera...@cvs.openbsd.org wrote: What has changed, however, is that the kernel has more kernel threads running (for instance, ps aguxk, and look at the first few which have the 'K' flag set in the 'STAT' field. In ps aguxk, what does the g do? I didn't find enlightenment on the man page or the Googles. These days it does nohing. It used to a flag up to 4.3BSD. Which showed more processes than the normally, like proceses not attached to your terminal and zombies iirc. -Otto -- PS: Apologies btw. for not responding to and thanking list members who wrote helpful replies after my graphics tablet question. That's one's kinda slipped through and I meant to get back to it, but...
Re: vmmap: bad software everywhere
@ Alexey Suslikov alexey.susli...@gmail.com wrote (2011-06-01 21:04+0200): Why do they need such a trick instead of simply storing tags in a associative array, where key is a pointer and value is a set of tags (or any other arbitrary data)? Lookup against properly aligned array is relatively fast. Am I missing something? May i answer this. One reason is of course space consumption. If you have 1 objects you need 1 hash nodes and i don't know how many indices the array shall have in this situation. And also, following a pointer chain is poison for CPU cache housekeeping. I.e. in that meaningless example // _area-owner-cbin_table[u.cbin-cbin_index] = u.cbin; you have to wait multiple times for memory to become available. And this is *really* expensive! -- Ciao, Steffen sdaoden(*)(gmail.com) () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
RFQ for ST39236LW
Hi You show in your Web-Site SEAGATE items. Please quote for 224pcs of ST39236LW Thank you for your cooperation Purchasing LTI Ltd. Tel : +972-9-7410210 AWB Fax: +972-9-7410873 www.lti.co.il Click here to remove your mail from our mailing list.
Exclusivo Taller de Contabilidad para NO Contadores
[IMAGE] Pms Capacitacisn Efectiva de Mixico presenta: Taller de Contabilidad para NO Contadores 21 de Junio Ciudad de Mixico. Expositor: Miguel Bustos Pineda Empresa Registrada ante la STPS Reg. COLG640205CP30005 Smguenos en Twitter@pmscapacitacion o bien en Facebook PMS de Mixico Solicite Mayores informes responda este correo electrsnico con los siguientes datos. Empresa: Nombre: Telifono: Email: Nzmero de Interesados: Y en breve le haremos llegar la informacisn completa del evento. O bien comunmquense a nuestros telifonos un ejecutivo con gusto le atendera Tels. (33) 8851-2365, (33)8851-2741. Copyright (C) 2010, PMS Capacitacisn Efectiva de Mixico S.C. Derechos Reservados. PMS de Mixico, El logo de PMS de Mixico son marcas registradas. ADVERTENCIA PMS de Mixico no cuenta con alianzas estratigicas de ningzn tipo dentro de la Republica Mexicana. NO SE DEJE ENGAQAR - DIGA NO A LA PIRATERIA. Todos los logotipos, marcas comerciales e imagenes son propiedad de sus respectivas corporaciones y se utilizan con fines informativos solamente. Este Mensaje ha sido enviado a misc@openbsd.org como usuario de Pms de Mixico o bien un usuario le refiris para recibir este boletmn. Como usuario de Pms de Mixico, en este acto autoriza de manera expresa que Pms de Mixico le puede contactar vma correo electrsnico u otros medios. Si usted ha recibido este mensaje por error, haga caso omiso de el y reporte su cuenta respondiendo este correo con el subject BAJAFINANZAS Unsubscribe to this mailing list, reply a blank message with the subject UNSUBSCRIBE BAJAFINANZAS Tenga en cuenta que la gestisn de nuestras bases de datos es de suma importancia y no es intencisn de la empresa la inconformidad del receptor. [demime 1.01d removed an attachment of type image/jpeg which had a name of contabilidad promo.jpg]
Re: I don't get where the load comes from
On 06/01/2011 10:16 AM, Christiano F. Haesbaert wrote: I had tinkered with a solution for this: Cron wakes up a minute before the batch run is scheduled to run. Cron will then copy a random 4kb sector from the hard disk to RAM, then run either an MD5 or SHA hash against it. The whole process would be timed and if it completed within a a reasonable amount of time for the system then it would kick off a batch job This was the easiest way I thought of measuring the actual performance of the system at any given time since it measures the entire system and closely emulates actual work. While this isn't really the right thing to do, I found it to be the most effective on my systems. You really think cron should be doing it's own calculation ? I don't like that *at all*. Can't we just have a higher default threshold for cron ? Can't we default to 0 ? I think this is something that should be looked up, if we admit load average is a shitty measure, we shouldn't rely on it for running cron jobs. I hereby vote for default to 0. (Thank god this isn't a democracy :-) ) Just have cron look at the system load average... ducking :)
Re: I don't get where the load comes from
On 1 June 2011 17:49, Theo de Raadt dera...@cvs.openbsd.org wrote: What has changed, however, is that the kernel has more kernel threads running (for instance, ps aguxk, and look at the first few which have the 'K' flag set in the 'STAT' field. In ps aguxk, what does the g do? I didn't find enlightenment on the man page or the Googles. These days it does nohing. It used to a flag up to 4.3BSD. Which showed more processes than the normally, like proceses not attached to your terminal and zombies iirc. It is such a bummer that we don't provide source code so that _educated_ people could read it. Oh wait, we provide source code. So access to source code isn't the problem? No it has never been the problem.
Para misc No te Pierdas Esta Obra Maestra Envio Sin Cargo A Toda La Argentina
Hola misc, si no podes visualizar este correo, podes hacerlo clickeando en este enlace. MOZART COMPLETE EDITION BOX-SET de 180 CDs en 4 DVDs La legendaria edicion The Complete Mozart Edition una tremenda obra maestra de 180 Cds Envio SIN CARGO a todo el Pais !!! Contiene material nunca antes sacado alpublico Para visitar la web haga clic aqui ((( Click Aca Arriba Si NO puedes Entrar))) El enlace no funciona? nbs p; Enlace alternativo clic aqui Suprimir su correo del boletin clic aqui ((( Haga Click Aca Para Ver Detalle Completo Y Comprar ))) Este e-mail tiene como unico destinatario: misc Para ser eliminado de nuestras listas envienos un email y en asunto aclarar REMOVER control de envio: pgjybfagwruytnzjlswzxme
License
Hello, I want to use the IPv6 source code in one of the products manufactured by my company and need to know if there are any restrictions or limitations regarding the use of source code in commercial products. Please let me know if this is not right place to enquire regarding the license. Thank you. Sincerely, Simranjit Gill Engage Communication.
Re: License
On Wed, 1 Jun 2011 18:02:23 -0700, Simranjit Gill wrote: I want to use the IPv6 source code in one of the products manufactured by my company and need to know if there are any restrictions or limitations regarding the use of source code in commercial products. Please let me know if this is not right place to enquire regarding the license. Thank you. Did you look at the source code? The licence is there for all the world to see. As it is with most sane software. *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ --- This life is not the real thing. It is not even in Beta. If it was, then OpenBSD would already have a man page for it.
fstab ext2fs duid patch
This is basically a rip off of ntfs_vfsops.c r1.25 and allows the use
of DUIDs in fstab for ext2fs.
Works for me on amd64 GENERIC.MP.
Index: ext2fs_vfsops.c
===
RCS file: /cvs/src/sys/ufs/ext2fs/ext2fs_vfsops.c,v
retrieving revision 1.59
diff -u -r1.59 ext2fs_vfsops.c
--- ext2fs_vfsops.c 21 Dec 2010 20:14:44 - 1.59
+++ ext2fs_vfsops.c 2 Jun 2011 03:25:01 -
@@ -44,6 +44,7 @@
#include sys/mount.h
#include sys/buf.h
#include sys/device.h
+#include sys/disk.h
#include sys/mbuf.h
#include sys/file.h
#include sys/disklabel.h
@@ -170,6 +171,7 @@
size_t size;
int error, flags;
mode_t accessmode;
+ char *fspec = NULL;
error = copyin(data, (caddr_t)args, sizeof (struct ufs_args));
if (error)
@@ -234,7 +236,11 @@
* Not an update, or updating the name: look up the name
* and verify that it refers to a sensible block device.
*/
- NDINIT(ndp, LOOKUP, FOLLOW, UIO_USERSPACE, args.fspec, p);
+ fspec = malloc(MNAMELEN, M_MOUNT, M_WAITOK);
+ error = copyinstr(args.fspec, fspec, MNAMELEN - 1, size);
+ disk_map(fspec, fspec, MNAMELEN, DM_OPENBLCK);
+
+ NDINIT(ndp, LOOKUP, FOLLOW, UIO_SYSSPACE, fspec, p);
if ((error = namei(ndp)) != 0)
return (error);
devvp = ndp-ni_vp;
@@ -286,8 +292,7 @@
bzero(fs-e2fs.e2fs_fsmnt, sizeof(fs-e2fs.e2fs_fsmnt) - size);
}
bcopy(fs-e2fs_fsmnt, mp-mnt_stat.f_mntonname, MNAMELEN);
- (void)copyinstr(args.fspec, mp-mnt_stat.f_mntfromname, MNAMELEN - 1,
- size);
+ size = strlcpy(mp-mnt_stat.f_mntfromname, fspec, MNAMELEN - 1);
bzero(mp-mnt_stat.f_mntfromname + size, MNAMELEN - size);
if (fs-e2fs_fmod != 0) {/* XXX */
fs-e2fs_fmod = 0;
@@ -298,6 +303,10 @@
mp-mnt_stat.f_mntfromname);
(void)ext2fs_cgupdate(ump, MNT_WAIT);
}
+
+ if (fspec)
+ free(fspec, M_MOUNT);
+
return (0);
}
Re: License
I want to use the IPv6 source code in one of the products manufactured by my company and need to know if there are any restrictions or limitations regarding the use of source code in commercial products. Please let me know if this is not right place to enquire regarding the license. Thank you. You can use it for anything. Ha-hah-hah. Guys, pile on.
Re: License
On Wed, Jun 1, 2011 at 6:02 PM, Simranjit Gill sim...@engageinc.com wrote: Hello, I want to use the IPv6 source code in one of the products manufactured by my company and need to know if there are any restrictions or limitations regarding the use of source code in commercial products. Please let me know if this is not right place to enquire regarding the license. Thank you. Check the FAQ and check the source. http://openbsd.org/faq/faq1.html#ReallyFree http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet6/in6.h?rev=1.53
Re: License
I want to use the IPv6 source code in one of the products manufactured by my company and need to know if there are any restrictions or limitations regarding the use of source code in commercial products. Please let me know if this is not right place to enquire regarding the license. Thank you. Seriously speaking, you can use any OpenBSD source code anywhere. Just a simple requirement which is spelled out in each source file. Read it. You can look at any source file here on the website http://www.openbsd.org/cgi-bin/cvsweb/src/ These are the goals and policies of OpenBSD http://openbsd.org/policy.html http://openbsd.org/goals.html This is one of the cleanest implementations of IPv6 source code. If you do use it, please a request, buy some CDs to help fund the project. You are probably going to get flamed by others. Don't use a public list to post such simple questions. This is addressed ad-nauseam elsewhere on the misc@ archives and probably in the FAQ somewhere.
Re: License
Simranjit == Simranjit Gill sim...@engageinc.com writes: Simranjit Hello, I want to use the IPv6 source code in one of the Simranjit products manufactured by my company and need to know if there Simranjit are any restrictions or limitations regarding the use of Simranjit source code in commercial products. Please let me know if Simranjit this is not right place to enquire regarding the Simranjit license. Thank you. Very sad for people's ability to read. The future looks bleak. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 mer...@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion
Re: I don't get where the load comes from
On Wed, Jun 1, 2011 at 11:49 AM, Theo de Raadt dera...@cvs.openbsd.org wrote: On 2011-06-01 15.53, Joel Wiramu Pauling wrote: On 2 June 2011 01:41, Benny Lofgren bl-li...@lofgren.biz mailto:bl-li...@lofgren.biz wrote: I agree with what you are saying, and I worded this quite badly, the frame I was trying to setup was back in the day when multi-user meant something (VAX/PDP) - the load average WAS tied to core utilization - as you would queue a job, and it would go into the queue and there would be lots of stuff in the queue and the load average would bumo, because there wasn't much core to go around. Not wanting to turn this into a pissing contest, I still have to say that you are fundamentally wrong about this. I'm sorry, but what you are saying simply is not correct. I've worked in-depth on just about every unixlike architecture there is since I started out in this business back in 1983, and on every single one (that employed it at all) the load average concept has worked similarly to how I described it in my previous mail. (Not always EXACTLY alike, but the general principle have always been the same.) The reason I'm so adamant about this is that the interpretation of the load average metric truly is one of the longest-standing misconceptions about the finer points of unix system administration there is, and if this discussion thread can set just one individual straight about it then it is worth the extra mail bandwidth. :-) 100% right. The load average calculation has not changed in 25 years. Anyone who says otherwise hasn't got a single fact on their side. What has changed, however, is that the kernel has more kernel threads running (for instance, ps aguxk, and look at the first few which have the 'K' flag set in the 'STAT' field. Some kernels have decided to not count those threads, others do count them. Since these kernel threads make various decisions for when to do their next tasks and how to context switch, the statistical monitoring of the system which ends up creating load values can get perturbed. That's what this comes down to. Which.. sounds exactly like a change in the load average calculation, due to kernel changes, that has occurred in the last 25 years.
Re: I don't get where the load comes from
100% right. The load average calculation has not changed in 25 years. Anyone who says otherwise hasn't got a single fact on their side. What has changed, however, is that the kernel has more kernel threads running (for instance, ps aguxk, and look at the first few which have the 'K' flag set in the 'STAT' field. Some kernels have decided to not count those threads, others do count them. Since these kernel threads make various decisions for when to do their next tasks and how to context switch, the statistical monitoring of the system which ends up creating load values can get perturbed. That's what this comes down to. Which.. sounds exactly like a change in the load average calculation, due to kernel changes, that has occurred in the last 25 years. You clearly cannot read. The calculation has NOT CHANGED. The way that work is done in the kernel has changed. You better get back to class; your potty break is over.
Re: I don't get where the load comes from
On Thu, Jun 2, 2011 at 12:48 AM, Theo de Raadt dera...@cvs.openbsd.org wrote: 100% right. The load average calculation has not changed in 25 years. Anyone who says otherwise hasn't got a single fact on their side. What has changed, however, is that the kernel has more kernel threads running (for instance, ps aguxk, and look at the first few which have the 'K' flag set in the 'STAT' field. Some kernels have decided to not count those threads, others do count them. Since these kernel threads make various decisions for when to do their next tasks and how to context switch, the statistical monitoring of the system which ends up creating load values can get perturbed. That's what this comes down to. Which.. sounds exactly like a change in the load average calculation, due to kernel changes, that has occurred in the last 25 years. You clearly cannot read. The calculation has NOT CHANGED. The way that work is done in the kernel has changed. You better get back to class; your potty break is over. Then perhaps lean to write. If you're measuring a different phenomenon, one that has different units, then it's a distinctly different *calculation* becuase you're measuring a distinct collection of objects. One may as well add up a restaurant bill, leave out the tax and tip, and say it's unchanged because I used the same plus signs. It's particularly confusing, as the original poster was confused, when trying to comparae prices, in this case system loads.
