jcarle

What you probably want is a Fluid Width Layout.

Seems like it's a browser issue that could be better answered in the Software forum.

It's the Intel ICH10R RAID. I can hit the 150MB+ range in my read but the problem is not with sequential read, it's with random I/O. The random I/O for simultaneously feeding data to a burner grows significantly for each burner added.

I have four burners that I use actively. The problem, is quite simply, a throughput issue. Buffer underrun protection is not a perfect solution and should not be relied upon. There's a miniscule gap left by the process that can, with poor quality or sensitive playback equipment, cause the device to halt while watching the movie. The problem is in two parts. The first is that the data stream must be kept up in raw throughput, which varies from 5.54MB/sec at 4x up to 22.16MB/sec at 16x. Burning four DVDs at 16x would require up to 88.64MB/sec of sustained transfer which most drives simply can't do. Four DVDs at 4x would only require 22.16MB/sec, which is easily done with even the most modest of drives, however this bring is to part two of the problem. Being random access. Obviously, the more DVDs that you burn simultaneously, the more there will dispersed random I/O all over the drive, which in turn jams up the drive command queue and can quickly bring the data throughput to a crawl. And of course, it cascades making it worse the more drives are trying to burn at once. Drive fragmention will also increase to compound the issue. With two 74GB Western Digital 10000RPM SATA Raptors running in RAID 0 with Pioneer DVR-216D SATA DVD-RWs drives, and fully defragmented data, I was never reliably able to burn more then two DVDs at 4x each at the same time (without buffer underruns). At three, I was sometimes able to manage to sucessfully burn without buffer underruns but the second anything would require disk activity (screen saver, windows service, e-mail that came in, anything), all three drives would underrun while the hard drives caught up. The only true solution for multi-drive burning is to burn from a high speed, high I/O device that can sustain the high load required for this. An SSD drive or a RAM drive are about the only devices on the market at this time capable of sustaining such demand.

What are you using to slipstream your updates?

Very much a false positive.

@rv31 : There's absolutely no Denial of Service in what he's doing. It's simply ping monitoring. @chunhin : I'm not sure if it's possible to do what you'd like with a batch file, but some simple scripting in VBScript could do the trick. Take a look at this topic.

@DreamSkape : Do not double post. You already have an open topic on this subject.

The site: command will show ALL pages which google has indexed, in an order only they know.

You could also make the checkbox initially hidden : <input id="checkboxNamedID" type="checkbox" style="display: none;"> Then in your javascript show it with : document.getElementById('checkboxNamedID').style.display = ''; And hide it again with : document.getElementById('checkboxNamedID').style.display = 'none';

Are your images outside the scope of the project?

Web browsers show content as they receive it. If a long period of time is going on before you see anything, then chances are as ReDucTor mentioned, that your content is being buffered on the server.

You must check the URLs used in the HTML links you have in your site map. They must point to the same domain as the one that hosts the sitemap.

If you're seeing this, chances are that your server does not support ASP.NET processing and is causing your browser to download the file instead of viewing the processed HTML output.

Um what? Excuse me. I think I choked when I read that. First of all, Page Table Entries are mapped to Virtual Address spaces. So you're already wrong. Now, Virtual Addresses are mapped to Physical Addresses and considering PAE stands for Physical Address Extension, you're wrong again Let's add on the fact that PAE extends the physical address size from 32 bits to 36 bits and the Page Table Entry is extended to 64 bits to deal with PAE, you're wrong again. Like tic-tac-toe, three Xs, you're out. Also only 51 bits are available for address bytes since 1 bit is used for the page size and 12 bits are used for operating system specific data or functions such as No eXecute.

It manages the page table. The translation is done by the CPU. I think you're the one who's not processing properly. Who provides the code to the CPU to do the conversion? Oh, yea, the memory manager. No. Technically, AWE has nothing to do with PAE. It is just a technique for a 32bit app to access very large armounts of RAM, but it is not PAE. If you have a bicycle without handle bars, do the handle bars have nothing do with the bicycle and therefore the handle bars are just a way to drive the bicycle? I really doesn't matter that you like it very much, a little or at all. If you need to simplify the terminology to your understanding, so be it, because you obviously have no real understanding of how any of these systems work. There was some confusion about a process' virtual address space couldn't point to to physical ram above 4G. This was my point. If the VA points >4G then you have executable code above 4G (you are not using AWE here). Considering that you cannot point to a Virtual Address above 4GB using a 32 bit application without AWE... perhaps you've discovered a way to create a Virtual Address wormhole using your flux capacitor.

The script could be cleaned up quite a bit by using Regexp to parse the Ping output instead. (See MSDN)

.NET Framework 1.0 - Supported Operating Systems: Windows 2000; Windows 98; Windows ME; Windows NT; Windows Server 2003; Windows XP (Reference: Microsoft Download Center)

You cannot control how long Google will retain the old information. As long as you keep using the new domain name and stop mentioning the old URL, overtime, the old information will be replace with the new one when Google comes around to update their database.

That's incorrect. HTML is code, even if it's base is as a markup language. You're thinking of code in your habitual usage of the word, although in his statement, it's technically correct: "A markup language is a set of codes that give instructions... " (Source: Wikipedia). Also see the definition of code. Furthermore, I fail to see where he mentioned or even vaguely made the illusion that he thought writing HTML was programming.

No one has contributed any newer update lists for Windows XP x64, sorry.

Oh the humanity!

1993 left the building a long time ago... perhaps it's time to refresh yourself with newer technology.

This is getting completely away from the OP's topic. Please keep the competition in check and in your pants and use PMs if there's a further problem.

There are some advantages that ASP/VBScript offer, as with any other scripted language (PHP included), it allows for quick writing of minor tasks. There's a lot of work required to do some simple things in ASP.NET sometimes and the choice between an older technology such as ASP and a newer one such as ASP.NET is proportional to the project being worked on. And in fact, sometimes I even prefer coding in ASP because when used properly in an environment that's not under a huge load, it can even be faster then ASP.NET in terms of performance due to it's reduced overhead. Ironically, the reduced initial overhead swings around to become a major overhead when scaled to a large number of users where the obvious advantages of ASP.NET compiled code starts to shine.