As the author of Syslinux/PXELINUX I found the article rather interesting and enjoyable.
Thank you for your useful software! Sadly I'm no longer using pxelinux since I switched to Windows, but I believe I'm still using your TFTP server.
Monoprice sells 32' USB extensions that have a repeater on the end. I'm not sure how they get away with just one repeater instead of two as seems mandated by the USB spec, but they do and it works.
sonic.net also has 20Mbps or up to 40Mbps broadband on Adsl+2 but 40 is dual line.
Yes, that's what I have. The 40Mbps dual-line "Fusion". Due to distance from CO, it gets 32Mbps, but it is a consistent 32Mbps.
The question isn't "How", its "Why".. money doesn't seem to be the big issue here, so why not spring for Server 2008R2 and manage all the boxes from there? it does all this updating/registering/etc your hacking together, and for around $800, versus your hourly rate x hours hacking, seems less expensive and the result is a heck of a lot more manageable. I'm all for the do-it-yourself type, but managing disk images? Yeah I can spend my time better elsewhere
No, it really does not do anything like what I'm doing... and anyway, setting this all up was lots of fun.
I'm not quite sure what you mean. How is 32 less than 6?
A typical Comcast package appears to be 15mbps, according to their site. Comcast Business Class does offer pretty good bandwidth, though.
"I purchased 12 copies of Windows 7 Ultimate OEM System Builder edition, in 3-packs. However, it turns out that because the hardware is identical, Windows does not even realize that it is moving between machines."
Yeah. I actually learned this after having purchased only one 3-pack, but went ahead and bought three more 3-packs just to be legal. With this much attention paid to my setup, I don't want to be caught pirating.
PXE, et al, use TFTP, if I remember rightly. In principle, there's nothing to stop the files being delivered by multicast FTP (yes there are at least three, they use Scalable Reliable Multicast, FLUTE or NACK-Oriented Reliable Multicast respectively). Since OS images and the games themselves don't differ between machines, if you have N machines you get file delivery about N times as fast. (About because lost packets are resent, so it's not truly linear improvement.)
Indeed, as mentioned in the blog, I was at one point trying to develop a UDP-based blog device protocol that would broadcast blocks back, on the assumption that all the machines would be loading the same data at the same time. However, when I got the system up and running without that, and didn't see any performance problems, I decided to abandon that idea and focus efforts elsewhere.
I can't imagine a single machine serving out over iSCSI to have performance acceptable to play any modern, intensive game. How's it all work?
I couldn't imagine it either, but it turns out it works fine. Obviously the load times aren't blazingly fast but no one has ever complained about them being slow either.
Note that most games load all data upfront. Once they've done that, the game runs without doing much I/O.
Also note that an iSCSI image can be fully cached client-side, so if you load the same game twice, it's probably going to load directly from RAM the second time. (Most games are 32-bit so there's a good 4GB of RAM in the machines doing not much other than disk cache.)
Yes, that's exactly what I'm doing -- PXE-booting the whole OS over iSCSI. I'll edit to make that clearer.
Honestly I'm kicking myself for not having written everything up before going public. The vast majority of people who saw the original post will not see the technical details.
It's a fair criticism. I wanted to make the desks lower but I also wanted the monitors to sit higher when folded up, and the desks were getting stupidly deep, so I had to compromise. In practice, though, people aren't typing at these desks, they're gaming, which in my experience (as someone with some RSI problems) is not as sensitive to desk height.
All coming in future blog posts. Subscribe or follow me on G+.
Yes but the base bandwidth used by games is actually quite small. Let's say (overestimate) that you have 10 input events per second that need to be broadcast. That's going to take maybe 100 bytes, tops. All the other players are receiving events from 10 people, so 1k each. Times 10 players. 10k per second. My bandwidth is 400x that.
Of course, that's not actually how most client-server games work. Rather, they send you updates just about the objects you can see. Which probably takes significantly more bandwidth than just broadcasting keypresses, but not 400x more bandwidth.
We've had times when all 12 of us joined a public TF2 server, and it worked out just fine.
50ms latency is within the range that games can hide using client-side prediction, though I think my connection usually gets better pings than that.
>> Playing games with your friends all in the same room: fun
>
> What about having a girlfriend instead?
What about having a girlfriend who is also a gamer and plays games with you and your friends?
Genetics explains why you look like your father, and if you don't, why you should.
