Its called segmented addressing. Its stupid, and I thought the computer industry learned from this already.
Basically the stance that microsoft has taken is that if you need to use PAE, you only need to run 1 application / server.
MSSQL has a PAE option, but it will consume all available memory and not release any of it.
Linux supports PAE too, but applications are still limited to a 3GB address space (when configured this way). Its only benefit is when you have more than 1 process that needs access to large amounts of memory, then the segemented addressing will still be faster than swapping.
This small mom&pop computer shop I used to work for way back in the day would charge you an extra 5% if you wanted to use amex. None of our amex paying customers really cared about that since it wouldn't really work out to that much more anyways, and they seemed to like the personalized service.
This is typical with most places here if you're just buying components, especially if its just something like ram and other low-margin / cost items.
[random@workstation BitTorrent-3.2.1b]$ python2./btdownloadcurses.py --max_upload_rate 100/home/random/src/redhat9.torrent These errors occurred during execution: error: Too many args - 0 max. run with no args for parameter explanations
I had to edit the source code, apparently the client specifies that the maximum number of arguments should be 0 in a lot of places.
Pretty easy to fix, so I just capped the default upload rate to something that shouldn't try to saturate a 100Mb connection =) I don't mind sharing, but I don't like uploading at 1.2MB/sec when I'm only getting 350KB/sec down.
non-executable user stacks aren't possible on some processors, such as x86. There are various performance-reducing hacks out there to emulate them, but they don't last long.
Opteron supposedly promises a non-executable stack, but since this product is vapourware, there's no way to verify that their implmentation isn't flawed.
operating kernels split it into non-pageable memory (usually for the kernel), and user-space. The kernel keeps its structures that it needs in this memory. But an operating kernel is completely independant from your application, at least in the sense that user application context + operating kernel providing low-level API to application. If you wrote your own application you could use up all 4GB of ram, you just wouldn't be able to benefit from the commercially/freely availiable operating systems out there.
the processors are capable of addressing 32bits of data. That doesn't mean that the chipsets have to have enough address lines to satisfy that, it just means that the MMU is capable of doing so.
Even if the stores started requiring signatures on EULAs at the counter, it would still not forgive the past transgressions of companies. Thats like saying I shouldn't be punished for theft because I stopped stealing.
they didn't. that's why computer makes/intel/amd/etc are struggling right now, people just aren't purchasing equipment. You don't need anything faster than a P3 500 to run XP and read your email.
Thats why you're seeing all these digital media hub features... that turn PCs into PVRs.
You don't really want to put more than 4 drives on a U160 bus, unless you really have to. You might not reach the write speeds, but the read speeds you'll definately exceed.
and? its not like the freedom of speech is really being protected in the united states either.
I mean, our leaders aren't using 1984 as a guide to the new world economy.
phht!
Its called segmented addressing. Its stupid, and I thought the computer industry learned from this already.
Basically the stance that microsoft has taken is that if you need to use PAE, you only need to run 1 application / server.
MSSQL has a PAE option, but it will consume all available memory and not release any of it.
Linux supports PAE too, but applications are still limited to a 3GB address space (when configured this way). Its only benefit is when you have more than 1 process that needs access to large amounts of memory, then the segemented addressing will still be faster than swapping.
on ix86, memory pulled 64 bits at a time. This is because MMX registers are 64 bits wide, and the FPU is capable of a precision of 80bits.
Doesn't mean the normal registers are wider than 32bits however. And there is only the one FPU.
from the beginning it was designed for portability.
it was originally written on dec alphas to make sure that no ix86isms made it into the code.
sure, if you include the surface area of all those fat fucks.
yeah, I get that now. its counter-intuitive however.
same thing.
I'm not convinced it worked anyways, my upstream was pretty steadily at 5Mb/sec during the whole process.
oh well. I already have all the files =) This BT thing has proven to be very useful.
This small mom&pop computer shop I used to work for way back in the day would charge you an extra 5% if you wanted to use amex. None of our amex paying customers really cared about that since it wouldn't really work out to that much more anyways, and they seemed to like the personalized service.
This is typical with most places here if you're just buying components, especially if its just something like ram and other low-margin / cost items.
[random@workstation BitTorrent-3.2.1b]$ python2 ./btdownloadcurses.py --max_upload_rate 100 /home/random/src/redhat9.torrent
These errors occurred during execution:
error: Too many args - 0 max.
run with no args for parameter explanations
You were saying?
=)
Oh, and because ext2/3 has sparse files, it won't actually consume 60GB on your hard disk. Just the 4KB or so for the inode entry.
You'll prolly get banned pretty quickly though if the administrator actually cares.
That's how this works. If you don't allow upstream connections, you're going to find out very quickly that your download rate will suffer.
I had to edit the source code, apparently the client specifies that the maximum number of arguments should be 0 in a lot of places.
Pretty easy to fix, so I just capped the default upload rate to something that shouldn't try to saturate a 100Mb connection =) I don't mind sharing, but I don't like uploading at 1.2MB/sec when I'm only getting 350KB/sec down.
non-executable user stacks aren't possible on some processors, such as x86. There are various performance-reducing hacks out there to emulate them, but they don't last long.
Opteron supposedly promises a non-executable stack, but since this product is vapourware, there's no way to verify that their implmentation isn't flawed.
anything that has had a history of being insecure will continue to have a history of being insecure as long as new functionality is added.
operating kernels split it into non-pageable memory (usually for the kernel), and user-space. The kernel keeps its structures that it needs in this memory. But an operating kernel is completely independant from your application, at least in the sense that user application context + operating kernel providing low-level API to application. If you wrote your own application you could use up all 4GB of ram, you just wouldn't be able to benefit from the commercially/freely availiable operating systems out there.
the processors are capable of addressing 32bits of data. That doesn't mean that the chipsets have to have enough address lines to satisfy that, it just means that the MMU is capable of doing so.
Even if the stores started requiring signatures on EULAs at the counter, it would still not forgive the past transgressions of companies. Thats like saying I shouldn't be punished for theft because I stopped stealing.
I don't happen to have a P2 400. I have a P3 500.
*shrugs* =)
they didn't. that's why computer makes/intel/amd/etc are struggling right now, people just aren't purchasing equipment. You don't need anything faster than a P3 500 to run XP and read your email.
Thats why you're seeing all these digital media hub features... that turn PCs into PVRs.
No, I'd show them my cock. I am quite proud of it after all. I nair it every week to keep excess hair off of it and I oil it daily.
So tell me now if you don't want to see my penis.
Drives can't share bandwidth between other devices because SATA only allows one drive per cable.
You'd still have to contend with the bandwidth of the PCI bus in any event, so you'd be limited to the max peak throughput of 133MB/sec theoretical.
You don't really want to put more than 4 drives on a U160 bus, unless you really have to. You might not reach the write speeds, but the read speeds you'll definately exceed.
higher throughput off the disk for reading the files == lower latency.
Its great if you're doing map development for quake. Compress all the files, cuts your load time by 3/4.
If you don't change the file (often) its a speed boost.