Re: softdeps enabled = poor "concurrent" access?
On 02/24/2010 07:41 AM, Artur Grabowski wrote: On Wed, Feb 24, 2010 at 1:20 AM, Noah McNallie wrote: Well, i've found on openbsd without sofdeps enabled it will do this just fine. But when enabling softdeps it will not. The 'uname' or 'ls' will take quite a while to complete. Simplified explaination. Without softdeps, your tar does one disk write and waits for it to finish, then ls does one disk read and waits for it to finish. Continue until done. With softdeps, tar will fill the whole buffer cache with writes, not letting any other process run, then ls will try to read one block, wait for at least one write to finish before it can get a buffer, but in the mean time, tar will be awoken by those writes finishing and schedule even more writes before ls gets the chance to run. It's slightly stupid and there have been experiments with diffs to make this better, but there's no functionality in the tree to deal with this currently. exponentially. Did I miss some evolution of the english language? I recently keep hearing abuse of this word everywhere. A multiplication by a constant was not an exponential function last time I did high school math. //art after reading this, i would guess it was enabling READPRIO in netbsd that fixed it, as that gives reading priority.. though softdeps did not stop increasing performance, tar files still extracted at ~25x the rate.. i dunno, you guys can write me down all you want, i won't even make fun of openbsd for not having a disk scheduler. and i still adore it, my next bat is at how to remove it's security implementations to speed it up. Noah McNallie n0ah
Re: softdeps enabled = poor "concurrent" access?
On Wed, Feb 24, 2010 at 12:02 PM, Noah McNallie wrote: > it is very fast for single process tasks, but when another process would > like to use the disk it seems to just let one hog everything I do believe that's Artur's response explained earlier.
Re: softdeps enabled = poor "concurrent" access?
Noah McNallie wrote: > please read latest post Doesn't get any lazier than that.
Re: softdeps enabled = poor "concurrent" access?
On 02/24/2010 04:52 AM, Jan Stary wrote: On Feb 23 19:20:28, Noah McNallie wrote: Hey guys. Noah here. I'd like to use openbsd on an older machine i have. I've had it on there before and never tested something that i've been testing on various operating systems lately. That's how well they do while under disk io load, concurrently. An example would be to tar -zxvf a large tarball and in another terminal, try to run a simple command. such as 'uname' or 'ls' or what have you. To test responsiveness. It may not be a very good test but it's a everyday usage test. Well, i've found on openbsd without sofdeps enabled it will do this just fine. But when enabling softdeps it will not. The 'uname' or 'ls' will take quite a while to complete. So, your system is "slow" _with_ softupdates? The machine is a 300MHz 2MB L2 sparc64 SUN Ultra 30. softdeps is almost required as it speeds up something like the extraction of a tarball exponentially. I'm guessing somewhere near 25x. It's very slow on this machine without sofdeps. So, your system is "slow" _without_ softupdates? it is very fast for single process tasks, but when another process would like to use the disk it seems to just let one hog everything, as the other process gets very poor performance. i'm still looking to find openbsd daily snapshots, maybe it's fixed, it was a problem in netbsd too until upgraded to HEAD from this month, and the issue had vanished. i find it strange, it seems like an issue that would have been around since the conception of the softdep code/sparc64 code. hence why i don't find apt to be 'fixed' as an implementation error in the latest openbsd. i feel perhaps the only reason it was 'fixed' in netbsd is because i compiled in it's two 'new' disk schedulers 'READPRIO' and 'PRIOCSCAN'. I hope mentioning netbsd is not off topic, i feel it's not as netbsd and openbsd inter mingle code at times. let me know. Noah McNallie n0ah
Re: softdeps enabled = poor "concurrent" access?
On 02/24/2010 05:10 AM, Tobias Ulmer wrote: On Wed, Feb 24, 2010 at 10:52:05AM +0100, Jan Stary wrote: On Feb 23 19:20:28, Noah McNallie wrote: Hey guys. Noah here. I'd like to use openbsd on an older machine i have. I've had it on there before and never tested something that i've been testing on various operating systems lately. That's how well they do while under disk io load, concurrently. An example would be to tar -zxvf a large tarball and in another terminal, try to run a simple command. such as 'uname' or 'ls' or what have you. To test responsiveness. It may not be a very good test but it's a everyday usage test. Well, i've found on openbsd without sofdeps enabled it will do this just fine. But when enabling softdeps it will not. The 'uname' or 'ls' will take quite a while to complete. So, your system is "slow" _with_ softupdates? No, softdep trades responsiveness for speed. The overall throughput increases, of course. I've discussed this with him on IRC some time ago. It was futile, he's hung up on thinking he can get the "impossible" by whining about it. This thread is as pointless as anything. The machine is a 300MHz 2MB L2 sparc64 SUN Ultra 30. softdeps is almost required as it speeds up something like the extraction of a tarball exponentially. I'm guessing somewhere near 25x. It's very slow on this machine without sofdeps. So, your system is "slow" _without_ softupdates? please read latest post Noah McNallie n0ah
Re: softdeps enabled = poor "concurrent" access?
On Wed, Feb 24, 2010 at 1:20 AM, Noah McNallie wrote: > Well, i've found on openbsd without sofdeps enabled it will do this just > fine. But when enabling softdeps it will not. The 'uname' or 'ls' will take > quite a while to complete. Simplified explaination. Without softdeps, your tar does one disk write and waits for it to finish, then ls does one disk read and waits for it to finish. Continue until done. With softdeps, tar will fill the whole buffer cache with writes, not letting any other process run, then ls will try to read one block, wait for at least one write to finish before it can get a buffer, but in the mean time, tar will be awoken by those writes finishing and schedule even more writes before ls gets the chance to run. It's slightly stupid and there have been experiments with diffs to make this better, but there's no functionality in the tree to deal with this currently. > exponentially. Did I miss some evolution of the english language? I recently keep hearing abuse of this word everywhere. A multiplication by a constant was not an exponential function last time I did high school math. //art
Re: softdeps enabled = poor "concurrent" access?
On Wed, Feb 24, 2010 at 10:59:12AM +0100, Bret S. Lambert wrote: > On Wed, Feb 24, 2010 at 10:52:05AM +0100, Jan Stary wrote: > > On Feb 23 19:20:28, Noah McNallie wrote: > > > Hey guys. Noah here. I'd like to use openbsd on an older machine i have. > > > I've had it on there before and never tested something that i've been > > > testing on various operating systems lately. That's how well they do > > > while under disk io load, concurrently. > > > > > > An example would be to tar -zxvf a large tarball and in another > > > terminal, try to run a simple command. such as 'uname' or 'ls' or what > > > have you. To test responsiveness. It may not be a very good test but > > > it's a everyday usage test. > > > > > > Well, i've found on openbsd without sofdeps enabled it will do this just > > > fine. But when enabling softdeps it will not. The 'uname' or 'ls' will > > > take quite a while to complete. > > > > So, your system is "slow" _with_ softupdates? > > > > > The machine is a 300MHz 2MB L2 sparc64 SUN Ultra 30. softdeps is almost > > > required as it speeds up something like the extraction of a tarball > > > exponentially. I'm guessing somewhere near 25x. It's very slow on this > > > machine without sofdeps. > > > > So, your system is "slow" _without_ softupdates? > > > > It's a floor wax, *and* a dessert topping! > dude they sell that at taco bell
Re: softdeps enabled = poor "concurrent" access?
On 24/02/2010 09:52, Jan Stary wrote: > On Feb 23 19:20:28, Noah McNallie wrote: >> Hey guys. Noah here. I'd like to use openbsd on an older machine i have. >> I've had it on there before and never tested something that i've been >> testing on various operating systems lately. That's how well they do >> while under disk io load, concurrently. >> >> An example would be to tar -zxvf a large tarball and in another >> terminal, try to run a simple command. such as 'uname' or 'ls' or what >> have you. To test responsiveness. It may not be a very good test but >> it's a everyday usage test. >> >> Well, i've found on openbsd without sofdeps enabled it will do this just >> fine. But when enabling softdeps it will not. The 'uname' or 'ls' will >> take quite a while to complete. > > So, your system is "slow" _with_ softupdates? > >> The machine is a 300MHz 2MB L2 sparc64 SUN Ultra 30. softdeps is almost >> required as it speeds up something like the extraction of a tarball >> exponentially. I'm guessing somewhere near 25x. It's very slow on this >> machine without sofdeps. > > So, your system is "slow" _without_ softupdates? > I think he means untar is faster but doing ls, uname etc is slower WHILE doing the untar. It's a fair enough question till you actually think about it. I think Tobias Ulmer summed it up best
Re: softdeps enabled = poor "concurrent" access?
On Wed, Feb 24, 2010 at 10:52:05AM +0100, Jan Stary wrote: > On Feb 23 19:20:28, Noah McNallie wrote: > > Hey guys. Noah here. I'd like to use openbsd on an older machine i have. > > I've had it on there before and never tested something that i've been > > testing on various operating systems lately. That's how well they do > > while under disk io load, concurrently. > > > > An example would be to tar -zxvf a large tarball and in another > > terminal, try to run a simple command. such as 'uname' or 'ls' or what > > have you. To test responsiveness. It may not be a very good test but > > it's a everyday usage test. > > > > Well, i've found on openbsd without sofdeps enabled it will do this just > > fine. But when enabling softdeps it will not. The 'uname' or 'ls' will > > take quite a while to complete. > > So, your system is "slow" _with_ softupdates? No, softdep trades responsiveness for speed. The overall throughput increases, of course. I've discussed this with him on IRC some time ago. It was futile, he's hung up on thinking he can get the "impossible" by whining about it. This thread is as pointless as anything. > > > The machine is a 300MHz 2MB L2 sparc64 SUN Ultra 30. softdeps is almost > > required as it speeds up something like the extraction of a tarball > > exponentially. I'm guessing somewhere near 25x. It's very slow on this > > machine without sofdeps. > > So, your system is "slow" _without_ softupdates?
Re: softdeps enabled = poor "concurrent" access?
On Wed, Feb 24, 2010 at 10:52:05AM +0100, Jan Stary wrote: > On Feb 23 19:20:28, Noah McNallie wrote: > > Hey guys. Noah here. I'd like to use openbsd on an older machine i have. > > I've had it on there before and never tested something that i've been > > testing on various operating systems lately. That's how well they do > > while under disk io load, concurrently. > > > > An example would be to tar -zxvf a large tarball and in another > > terminal, try to run a simple command. such as 'uname' or 'ls' or what > > have you. To test responsiveness. It may not be a very good test but > > it's a everyday usage test. > > > > Well, i've found on openbsd without sofdeps enabled it will do this just > > fine. But when enabling softdeps it will not. The 'uname' or 'ls' will > > take quite a while to complete. > > So, your system is "slow" _with_ softupdates? > > > The machine is a 300MHz 2MB L2 sparc64 SUN Ultra 30. softdeps is almost > > required as it speeds up something like the extraction of a tarball > > exponentially. I'm guessing somewhere near 25x. It's very slow on this > > machine without sofdeps. > > So, your system is "slow" _without_ softupdates? > It's a floor wax, *and* a dessert topping!
Re: softdeps enabled = poor "concurrent" access?
On Feb 23 19:20:28, Noah McNallie wrote: > Hey guys. Noah here. I'd like to use openbsd on an older machine i have. > I've had it on there before and never tested something that i've been > testing on various operating systems lately. That's how well they do > while under disk io load, concurrently. > > An example would be to tar -zxvf a large tarball and in another > terminal, try to run a simple command. such as 'uname' or 'ls' or what > have you. To test responsiveness. It may not be a very good test but > it's a everyday usage test. > > Well, i've found on openbsd without sofdeps enabled it will do this just > fine. But when enabling softdeps it will not. The 'uname' or 'ls' will > take quite a while to complete. So, your system is "slow" _with_ softupdates? > The machine is a 300MHz 2MB L2 sparc64 SUN Ultra 30. softdeps is almost > required as it speeds up something like the extraction of a tarball > exponentially. I'm guessing somewhere near 25x. It's very slow on this > machine without sofdeps. So, your system is "slow" _without_ softupdates?
Re: softdeps enabled = poor "concurrent" access?
BTW this is great paper about SoftUpdates and journaling http://www.usenix.org/publications/library/proceedings/usenix2000/general/full_papers/seltzer/seltzer_html/index.html which I found as link in old interview with Theo http://kerneltrap.org/node/6 I know now more about meta-data and similar stuff. On Wed, Feb 24, 2010 at 1:20 AM, Noah McNallie wrote: > Hey guys. Noah here. I'd like to use openbsd on an older machine i have. > I've had it on there before and never tested something that i've been > testing on various operating systems lately. That's how well they do while > under disk io load, concurrently. > > An example would be to tar -zxvf a large tarball and in another terminal, > try to run a simple command. such as 'uname' or 'ls' or what have you. To > test responsiveness. It may not be a very good test but it's a everyday > usage test. > > Well, i've found on openbsd without sofdeps enabled it will do this just > fine. But when enabling softdeps it will not. The 'uname' or 'ls' will take > quite a while to complete. > > The machine is a 300MHz 2MB L2 sparc64 SUN Ultra 30. softdeps is almost > required as it speeds up something like the extraction of a tarball > exponentially. I'm guessing somewhere near 25x. It's very slow on this > machine without sofdeps. > > Any help leading to a sollution is more than apreciated! > > Noah McNallie > n0ah > > -- http://www.openbsd.org/lyrics.html
Re: softdeps enabled = poor "concurrent" access?
Not. You can run OpenBSD 4.6 and run 4.6-Release, 4.6-Stable(Release + patches) or 4.6-Current. So 4.6 doesn't say much about what in fact you are running. The description of each one is in : http://www.openbsd.org/faq/faq5.html#Flavors But, only your dmesg could say exactly what you are running and what OpenBSD found(hardware, sensors, ...) in your machine. On Wed, Feb 24, 2010 at 1:19 AM, Noah McNallie wrote: > On 02/23/2010 08:47 PM, Bryan wrote: >> >> where's your dmesg? have you tried a -current snapshot? >> >> On Tue, Feb 23, 2010 at 18:20, Noah McNallie wrote: >>> >>> Hey guys. Noah here. I'd like to use openbsd on an older machine i have. >>> I've had it on there before and never tested something that i've been >>> testing on various operating systems lately. That's how well they do >>> while >>> under disk io load, concurrently. >>> >>> An example would be to tar -zxvf a large tarball and in another terminal, >>> try to run a simple command. such as 'uname' or 'ls' or what have you. To >>> test responsiveness. It may not be a very good test but it's a everyday >>> usage test. >>> >>> Well, i've found on openbsd without sofdeps enabled it will do this just >>> fine. But when enabling softdeps it will not. The 'uname' or 'ls' will >>> take >>> quite a while to complete. >>> >>> The machine is a 300MHz 2MB L2 sparc64 SUN Ultra 30. softdeps is almost >>> required as it speeds up something like the extraction of a tarball >>> exponentially. I'm guessing somewhere near 25x. It's very slow on this >>> machine without sofdeps. >>> >>> Any help leading to a sollution is more than apreciated! >>> >>> Noah McNallie >>> n0ah >> >> > > if by -current snapshot you mean openbsd 4.6 then yes, that's what i'm > using. > > Noah McNallie > n0ah
Re: softdeps enabled = poor "concurrent" access?
On Tue, Feb 23, 2010 at 7:19 PM, Noah McNallie wrote: > if by -current snapshot you mean openbsd 4.6 then yes, that's what i'm > using. > > By looking at the head of dmesg(8) output or by the following command: $ sysctl kern.version ...you will get information pertaining to the version installed. If all that is mentioned is "OpenBSD 4.6", you are running -release. -stable or -current is mentioned explicitly if these versions are actually installed. Even if "OpenBSD 4.6-current" is displayed, this indicates a version which is several weeks old. Recent snapshots of -current all sport "OpenBSD 4.7-beta". To understand the difference between -release, -stable, & -current, study FAQ 5.1.
Re: softdeps enabled = poor "concurrent" access?
On 02/23/2010 08:47 PM, Bryan wrote: where's your dmesg? have you tried a -current snapshot? On Tue, Feb 23, 2010 at 18:20, Noah McNallie wrote: Hey guys. Noah here. I'd like to use openbsd on an older machine i have. I've had it on there before and never tested something that i've been testing on various operating systems lately. That's how well they do while under disk io load, concurrently. An example would be to tar -zxvf a large tarball and in another terminal, try to run a simple command. such as 'uname' or 'ls' or what have you. To test responsiveness. It may not be a very good test but it's a everyday usage test. Well, i've found on openbsd without sofdeps enabled it will do this just fine. But when enabling softdeps it will not. The 'uname' or 'ls' will take quite a while to complete. The machine is a 300MHz 2MB L2 sparc64 SUN Ultra 30. softdeps is almost required as it speeds up something like the extraction of a tarball exponentially. I'm guessing somewhere near 25x. It's very slow on this machine without sofdeps. Any help leading to a sollution is more than apreciated! Noah McNallie n0ah if by -current snapshot you mean openbsd 4.6 then yes, that's what i'm using. Noah McNallie n0ah
Re: softdeps enabled = poor "concurrent" access?
On 02/23/2010 08:47 PM, Bryan wrote: where's your dmesg? have you tried a -current snapshot? On Tue, Feb 23, 2010 at 18:20, Noah McNallie wrote: Hey guys. Noah here. I'd like to use openbsd on an older machine i have. I've had it on there before and never tested something that i've been testing on various operating systems lately. That's how well they do while under disk io load, concurrently. An example would be to tar -zxvf a large tarball and in another terminal, try to run a simple command. such as 'uname' or 'ls' or what have you. To test responsiveness. It may not be a very good test but it's a everyday usage test. Well, i've found on openbsd without sofdeps enabled it will do this just fine. But when enabling softdeps it will not. The 'uname' or 'ls' will take quite a while to complete. The machine is a 300MHz 2MB L2 sparc64 SUN Ultra 30. softdeps is almost required as it speeds up something like the extraction of a tarball exponentially. I'm guessing somewhere near 25x. It's very slow on this machine without sofdeps. Any help leading to a sollution is more than apreciated! Noah McNallie n0ah I will try this tomorrow. Noah McNallie n0ah
Re: softdeps enabled = poor "concurrent" access?
where's your dmesg? have you tried a -current snapshot? On Tue, Feb 23, 2010 at 18:20, Noah McNallie wrote: > Hey guys. Noah here. I'd like to use openbsd on an older machine i have. > I've had it on there before and never tested something that i've been > testing on various operating systems lately. That's how well they do while > under disk io load, concurrently. > > An example would be to tar -zxvf a large tarball and in another terminal, > try to run a simple command. such as 'uname' or 'ls' or what have you. To > test responsiveness. It may not be a very good test but it's a everyday > usage test. > > Well, i've found on openbsd without sofdeps enabled it will do this just > fine. But when enabling softdeps it will not. The 'uname' or 'ls' will take > quite a while to complete. > > The machine is a 300MHz 2MB L2 sparc64 SUN Ultra 30. softdeps is almost > required as it speeds up something like the extraction of a tarball > exponentially. I'm guessing somewhere near 25x. It's very slow on this > machine without sofdeps. > > Any help leading to a sollution is more than apreciated! > > Noah McNallie > n0ah
softdeps enabled = poor "concurrent" access?
Hey guys. Noah here. I'd like to use openbsd on an older machine i have. I've had it on there before and never tested something that i've been testing on various operating systems lately. That's how well they do while under disk io load, concurrently. An example would be to tar -zxvf a large tarball and in another terminal, try to run a simple command. such as 'uname' or 'ls' or what have you. To test responsiveness. It may not be a very good test but it's a everyday usage test. Well, i've found on openbsd without sofdeps enabled it will do this just fine. But when enabling softdeps it will not. The 'uname' or 'ls' will take quite a while to complete. The machine is a 300MHz 2MB L2 sparc64 SUN Ultra 30. softdeps is almost required as it speeds up something like the extraction of a tarball exponentially. I'm guessing somewhere near 25x. It's very slow on this machine without sofdeps. Any help leading to a sollution is more than apreciated! Noah McNallie n0ah
