I agree completely. It actually reminds me of people who buy gas to drive to work for 30 odd years, till it suddenly triples in price and people start wondering what happened to all the damn oil.
Replace oil with any limited resource (land, water, beaches, hardwoods, ivory).
Rules make games. Bitching about rules that go against you when you play a game is like buying a car then bitching to everyone how you have to buy gas for it to work. People who complain that games are too hard, shouldn't play them, they aren't all meant to be chinese checkers or yahtzee.
EQ was too hard? Then you plain sucked at it. Accept it, go home, pull out one of the millions of 3D FPS's, and use a god cheat. Or better yet, pay a prostitute to tell you how large your dick is, because things in life have value equal to the effort put into them, which is why gold costs more than shit, and why they don't give nobel prizes to people who sit around drinking beer.
If it wasn't a fun game, why did/do so many people play it as much as they did?
Just tired of people expecting everything to be mindlessly easy. Life is meant to be a challenge, that's why so many people die from it.
EQ/Vanguard are not for people who enjoy playing mmorpgs, like they enjoy playing other games, or for people who play them like glorified IM clients. These games are for the people who actually enjoy the challenge, enjoy the fact that it might take hours to get a reward, and instead of hating the process, count it as an effort towards building a character they see value in.
This is like saying MGS 2 was too hard because you couldn't play it like Tetris or Solitaire, they are totally different types of games. In WoW, the actual work done by the player is minimal, with low risk, and even unskilled/casual players (which is a huge, HUGE market) can compete evenly with the hardcore players. They are actually different games, and the problem until now has been trying to expand the market with new unskilled players, while still keeping the hardcore tier-1 dragon-slayers with server-uniques which are critical to the game, like the old FoH and LoS guilds were to EQ, setting an inspiring ideal for the rest of the players to follow, part hero-worship, part social-hierarchy.
My point is they are different audiences completely. Trying to put them in the same game is difficult without either pissing off the casual players, or letting the hardcore players reach the "End". WoW tried, and got an assload of casual players, but most of the hardcore players I know have left, doing cameos whenever a new dragon comes out, and otherwise actually getting on with their lives. The only hardcore players in WoW now are the compulsive "Ok now I want armor X and horse Y so I look cooler" until the next patch comes out with new armor X and horse Y.
Final Fantasy 1 for the NES: Long game with lots of little details and weapons. Played better than most genesis games.
Phantasy Star 4 for the genesis. Not many played it, but it was long, complex, played nearly like an early ps1 game. Decent storyboard cinematics, and best gfx in an rpg for its system.
Final Fantasy 9 for the PS1: plays like a PS2 game for sure.
Ultima Underworld and The Summoning: both played on a 286, UW was a first person doom-dungeon trip, the summoning was a colorful and complex wizardry clone.
These aren't just games that push the systems, these are also games that put design before production, ie. concept above code, with consistency and playability above quick flashy gfx features (remember mode 9?) and uncontrollable cutscenes that are added because they look good in demo videos.
Castlevania:SOTN gets the other side of this award tho, for making the most crazy fun, but technologically backwards game this side of tetris plus.
XFS has issues that go version by version. I've had volumes work perfectly for months suddenly start spitting out I/O spam after a simple kernel upgrade. My guess is poorly applied patches, as many xfs kernel patches are added downstream by a distro or kernel contributor (MM/gentoo). just my 2c, YMMV.
if solaris is an option go zfs. hands down best fs if you can run it, incredible flexibility and scalability.
also, you mentioned something about burning to dvd, filesystems won't really help with that, i'd look more into taring your filesystem/ fs segments into disc sized segments, then making extra par2 files for error-resilience.
really, backing up 2tb of live data is a f*ing nightmare however you look at it, usually when i reach that hurdle i just build another machine, copy over active data, and put the old box in the closet, a sort of living backup if you will, if i ever need to go back to it. at the cost of hd's now, especially with removable sata chassis's it's the only way to handle the sheer size of data you'll be dealing with.
reiser or jfs are both solid for this kind of work, with large file and volume support. personally i swear by reiser for my 2tb volume, and have had no problems so far, although there is a minor speed penalty when working with several multi-gigabyte files at once, something to do with shared fs locks/mutexes i'd imagine.
OTOH JFS is quite stable, and though it has less of the elegance in feature set I find in reiser, tends to make up for it with enhanced ruggedness and its handling of large volume/files.
Really can't recommend anything else, as you say, reiser4 is still untested for reliability imho, xfs has issues that vary from kernel to kernel, and ext3 appears quite primitive in comparision, although its journaling seems comparable to the other choices.
JFS if you need the speed, its dead fast in large scales, slower with small files, otherwise Reiser3 is an excellent all-round performer.
ahem, my point is the emotion and overall meaning come across better in the original japanese.
No, it is horrendously confusing, but that's because it's complex, and doesn't take the time to explain everything for the slowest kid in the class like american media. Takes a few passes to get most of the meaning, but I didn't understand most of the plot of the second season till i got a new fansub of the ending ep.
In Asia, being smart is something to be proud of, like being attractive, vs. here where it's something to hide so you can seem like everyone else. It's a different approach to social interaction and hierarchy, and took me completely off guard when I first noticed it, compared to growing up in rural indiana and tn.
Are we Americans growing so illiterate that we can't even be bothered to read subtitles for foreign-made films?
uhh, yes?!
on another note, i've given up on english translations. GITS season 2 had atrocious voice-dubbing, and without the original japanese the series loses so much of its meaning. Hearing a anti-tank helicopter pilot sound like the cocky "Mav" from top-gun destroys the ambiance of what is meant to be a complex, thoughtful series. It's like trying to watch a ferrelly brothers movie dubbed into german, it's stupid, AND it doesn't make any sense.
I have little hope for AD dubbed into english either, a lot of anime japanese is too complex to easily translate between cultures, and we don't exactly have attention spans over here.
security: depends on your config, but without a pdc, cert authority and a good bit of other addons, windows networking doesn't have the real framework to support real security. Also, while the permissions model is functional, it is not always consistent, and often needs to be configured by hand to maintain proper security levels. For real high security applications, either a windows pdc or solaris nfsv4 would be needed, but for common working environments nfs is generally more secure, and more easily securable. Part of it depends on your sysadmins skillset I guess.
NFS is faster, much, in actual access, latencies, transaction times. SMB requires full tcp connection requests per access, which allows for high transfer rates of large sequential files, but means for a large number of small files, or multiple seek/operation accesses of large files, SMB is pretty damn laggy. There are benches of this. NFS uses a more complex, low-level udp to kernel inode system that allows for a far lower latency time. Really something you have to see to understand, I have a 2tb raid5 on an 8-pt areca pcie x8 which can fill my gige connection, and nfs is much faster than local file access vs smb which has minor transaction lags whenever the sequential stream has to be seeked or restarted, or new files are opened.
The real bottleneck here is the protocol, and kernel-mode nfs is much lighter and thinner than user-mode samba, but you really can't understand till you try it.
My holy grail is to find a good system to build a mATX server out of, with gigE and possibly raid5 on 5 drives. Alas so far I've never managed it, although it is possible by mangling an antec aria.
NFS only for "mac/linux"? What about Solaris, *BSD and Microsoft Windows?
Yes, but considering the OP doesn't sound like he knows the basics of raid or sharing and is looking for a smb solution, WTF is the chance that he's running solaris 10 on an SF25k??
NFS faster? That depends very much on your setup.
Real world, GigE, as long as all the files are not less than 5mb NFS blows smb away. The latency is less than a third, transaction time less than half. SMB starts a new connection each file, and seeks are synchronous. Performance sucks unless you're just streaming files sequentially. Try it and see.
NFS is better? In what way? NFSv3 is a security hole, whilst NFSv4 is best implementented on Solaris.
Funny, I'd say Windows is a security hole, smb rides on the already crippled windows networking authentication system, including the broken kerberos, and unless you have a machine to set up and money to pay to run a PDC, don't even hope to have a secure server. Basically a domainless windows network is open, no matter how you try to secure it. NFSv4 is best on solaris, no question, but any version is better than any version of smb, short of samba to samba on linux boxes only.
Actually I agree, but it's usually not practical. Linux software raid is ub3rl33t, but relatively annoying to boot off of. I used to set aside small partitions on all my raid drives to boot and root from, with the data going on the main raid partitions, but its not fun, nor elegant.
Sorry only read half your article the first time. Started out on slack. Good times...
use the async,vers=2 line in both fstab and export options, and the size options. There is also an issue with datagram defragmentation, which is fixed via/proc/sys/net/ipv4/ipfrag_high_thresh and low_thresh, my values are 256k and 192k respectively.
Mostly though I'm pretty sure youre just running in sync mode, which is unGODLY slow at 1k rwsizes. Set that to async and preferably vers=2 and you should be screaming.
And yes, trying to work this out blindly on the web is a nightmare, I spent a half a week playing with settings and experimenting the first time, and hope never to do so again.
Actually yes. I went on an nfs tuning jihad a year ago. The results varied, sometimes I got a huge improvement, sometimes none at all between different boxen/configs. This is for linux only btw, tuning solaris for nfs is a totally different monster.
Most of the tuning faqs i went through were crap and elementary once you get to gigE an such. My current settings are simple:
mount options: rsize=8192,wsize=8192 : Best I've seen so far, and works well with jumbograms, have experimented with everything between 1024-32768 in both udp and tcp. noatime
export options: async,vers=2 : If you just need speed, big improvement because mount tends to ignore async in negotiation a lot
1. SMB only? NFS is faster and plain better, but only for mac/linux. 2. Noise/size/power constraints. 3. Price.
SMB only, moderately cheap, quiet and small, go for a teraserver from buffalo networks. Easy to setup, runs decently, 4x250 drives that can be raid-5'd into a 750 array. Costs about $800.
A good midlevel solution is an nforce4 motherboard, with 4 250 sata drives, total cost around $600 w/ cpu mem, etc. You need a decent case though, and it will be noisier and louder. Plus side is better performance, full customization, and ability to use it as a router or such. You will have to configure it yourself, and likely throw windows on it because the nforce raid support is tricky on linux for a novice.
I use a heavier 2tb solution myself with a HW raid card, but for most purposes a sw raid is better, and the performance difference is almost never noticable. Personally I recommend the buffalo if you don't need nfs, just for the size, quietness, and convenience.
Good reply. I'm not trying to write-off chip speeds, but as a programmer I'm aware we can't just count on the fact that this bloated, single-threaded program/game which slugs around now will work fine 1 year from now when the processors catch up.
Second, multi-chip cpu's do work, the gpu is essentially a graphics slave to the primary, specialized for its tasks, with access to primary memory, and using specialized (tho with need of improvement) mechanisms to offload work from the cpu. TCP offload adapters are similar if not the same. How are multi-chip processors dying? Even the new physics addons are attached via high speed interface. The new line of high speed busses and interconnects are easily capable of handling the data and latency. How do Opteron's share each other's memory and IO otherwise via a simple HT link?
Ok, Yonah blows my intel idea, but my point was that Yonah wasn't a blind "design it first, then just try to keep shrinking it" like prescott.
Anyway, I would suggest that to make 1,000 threads run well, most modules would have to be replicated at least 250 times.
Or, make a version of an ALU that can SIMD 16-32 similar operations at once, and schedule accordingly.
Finally, no, there is almost no way we could keep a 1000-thread chip full today. That is not a flaw of the chip, or concept, but of our current programming methodology. Are you honestly telling me there is no way to change the language, or design guidelines to unroll loops in parallel? Assuming only 200 are going to be running at any time due to memory/IO/waits, you have less reason to be so focused on branch prediction or cache misses. So a thread misses a couple cycles waiting on memory, the penalty is miniscule. Have 2 branches to choose from? Choose both, and discard the unused one. For loops can be coded as dependant, or independant, or in the case of DSP like functionality, unrolled with the pointers tracked automatically, parallelizing the operation completely. All this could be done if not today, than soon, without waiting for a 200x increase in clock speeds, which may or may not happen, and with few or none of the drawbacks. All the eye candy in modern os's? Free of charge, because that is just processor power that would be wasted otherwise. Who needs a gpu, your cpu can do that as well or better with an internal geometry unit, with no need for seperate memory.
The point is once the individual operation cost drops because of massive parallelization, the entire way of looking at programming and computers in general can be changed so the current high-revving, but stop for roadbumps viewpoint can be replaced with a steady convoy of trucks metaphor. Every instruction your computer executes is not dependent on every instruction executed before it, that is a restriction placed on computers by us, for debugging purposes and because multi-threaded chips were more expensive than high speed chips until recently, a product of CMOS fabrication technology. We still use processor interrupts for similar reasons, even though they are a huge performance hit unless done properly, and have been removed as far as possible from modern software and hardware designs.
Single threading is just a legacy frame of mind, because debugging dozens of threads without the right tools is hard. Once we develop the right tools, why in god's name would we want to run 1 thread at a time? Just imagine massive multithreading as the next generation of the superscalar architecture used in current chips. Take it to the next level, and blur the lines between current threads and a superscalar scheduler instead of handicapping yourself by forcing dependency scheduling on chip by dedicated circuits that have very little idea of the actual dependencies and execution flow, and less ability to flexibly reschedule for efficiency.
a: I think I misspoke. When I said that at smaller feature size, resistance goes down, I was also considering leakage as a failure of resistance. You're right, the current 90nm designs do use less power, the amd design in particular because it uses SOI to compensate for increased leakage, while I don't believe intel has soi on its chip line yet. At these scales, execution tends to matter as much as size, and my earlier point of blindly scaling down in hope of finding more gains from the magical process shrink becomes much more of a challenge.
2: Also, in a 1000-thread chip, not nearly all the parts of such a chip would have to be replicated. Much of current superscaler design relies on scheduling for as efficient usage of pipeline segments as possible, to allow for the maximum chip usage. This same approach could work, by turning l1 cache into an effective register file, and simply having a part of the chip whose role is to schedule prioritized register sets to the requisite resources. At the extreme this could even allow decoupled pipelines, such that the decode, memory load and IO intructions are executed in a primary stage chip dedicated to preprocessing and high wait state instructions, then passed on via HS interconnect to 1 or more secondary processors to perform the actual arithmetic, even allowing whole chips to perform the ancilliary functions such as the sound or GPU today, while being tightly coupled to the memory and processor state.
My point is that from this point on, threading will scale much faster than clockspeed. Even now, it is easier to make a second core than to double the clockspeed for the faster processors, and unless the leakage issue from tfm is solved soon this won't change.
Plus, once you have the right programming language support, with auto-parallelizing iterands, and self-dispatching async subroutines, who needs a fast chip, the actual instruction pointer, the current limiting factor, becomes meaningless, with all actual work being done parallel automatically, dependencies and resource sharing solving themselves by language design. A 1Ghz multithreaded chip can be as effective as a 4.0 Ghz prescott today, without even including the specialized instructions (SIMD, fast fp) that can boost actual efficiency through the roof, and be compiled in as static asynchronous subroutines dispatched parallel to the "main" thread.
Smaller transistors should have less gate capacitance, and so be capable of switching more quickly.
is:
Smaller transistors will have less resistance, and so will dissipate more power.
Which is why the P4 prescott, while a marvel on the drawing board, is pretty crappy in reality. 90nm technology has largely been an attempt to find a happy medium between higher capacitance and lower resistance, both of which limit speed. The current "nucular age" of chips is a direct by-product of ignoring the drop in resistance until it was too late.
Also, at 4+ Ghz an current-induced EM field has many of the properties of a microwave beam, which can resonate, and essentially self-focus on any imperfections in the semi-conductor structure, essentially burning small holes in the chip, or causing signal noise unless perfectly grounded (which in itself causes inductive leakage). This is why intel and amd have speed-bins, because the chips with the fewest imperfections are able to perform at the highest clockspeeds without thermal or electric failure.
My point is, the mega-hurts race, even assuming one or more miracles of metal-oxide chemistry, is ending. I look forward to the multi-proccessing race which seems to be heating up, as a long-postponed, but neccessary next step. The sad obstacle holding back the day of 1000-thread chips has been programmers complete lack of willingness to move beyond the single-threaded debugging paradigm. As one myself, I understand why it's seen as hard as it is, but consider it more of a viewpoint shift, rather than an insurmountable increase in complexity. New languages/language changes will happen to simplify threaded programming, and new mechanisms like auto-synchronized data structures, self-unrolling iterands, and integrated message-passing stacks will replace old-standbys. The mega-threading doomsday scenario will fall along the wayside with other past programmer nightmares such as the death of the goto loop and the loss of direct memory access in java and higher level languages, left only as subjects of nostalgia.
Hah! We of the pastafarian faith all snicker as you infidels again try to measure space not knowing that his noodly appendage has changed your observation to a space-time vortex.
Just as the bones of dinosaurs and the stars in the sky were placed by our noodly master, so is this great work of his doing.
Avast ye ignorant dogs! Worship ye great master and his wee midget. For he be a harsh mistress, and his noodly wrath shall send ye all down to Davey Jones's Locker!
I think lawyers are starting to learn that techies can't be bullied as easily as most, because techies are able to build new infrastructures. Instead of giving up, techies take threats as a challenge or motivation to dive further and further away from public vision.
while lawyers otoh, get paid by the hour. sit back and grab a beer, this fight ain't going nowhere.
seriously, it's like the cold war, it's against lawyers interests for either side to win, endless escalation is killer for billable hours. this kind of thing has been happening in every field of industry, blame the US for producing way too many of the vermin.
True, but I've heard of this kind of thing happening quite frequently from my friends in the ahem, military equipment sector.
Not that they say it happens to them, but the stories are ridiculous, with tests designed so they can't fail, or so failures are marked as partial successes, etc, because the project cannot have any black marks against it till acquisition... after which the govt will gladly pay to upgrade baselines to fix the flaws over the next decade. Check fas.org, but the first sparrow missle, the first line of tomahawks, b1 bomber, osprey, bradley's, even the proposed missle shield, all were/are acquired with obvious, mission-comprimising flaws that cost billions-10s of billions per project to fix. The problem is the acquisition system, especially congress's oversight, doesn't have an independent verification mechanism to prove that said equipment works within required parameters, and anyone who tries to say anything generally gets discharged from the military for going outside the chain of command and "comprimising the integrity of a classified project", even if the congressmen have clearance.
So if you were ever curious why so many ex-military officers found surprisingly comfortable jobs in the defense sector, theres an idea.
The corruption in the military-industrial complex goes beyond anything we can imagine in the private sector. Actual results being valued far less than pork per district works great in politics, but tends to hurt 2 politically defenseless groups, the taxpayers who fund these nightmares, and the poor troops who end up wondering why they have to bolt sheet metal onto their hummvees while people are shooting at them.
If we do not have oil to use, as we do now, how have we not run out of oil. When I say "oh im out of milk", I don't mean the last cow has died and no more exists in the world, I mean I have no practically accessable milk until I resupply from the store.
Economically useful oil running out is a serious threat, because, well we kind of depend on it right now, hence the point. Technically the world is producing more oil as we speak, but so slowly and unreachably that it effectively does not exist to us.
Being philosophical about the existence or non-existence of a common economic commodity is like trying to prove God exists so you don't have to go to work tomorrow.
Slashdot Mirror
I agree completely. It actually reminds me of people who buy gas to drive to work for 30 odd years, till it suddenly triples in price and people start wondering what happened to all the damn oil.
Replace oil with any limited resource (land, water, beaches, hardwoods, ivory).
Would be easier if we just ran out of people.
Rules make games. Bitching about rules that go against you when you play a game is like buying a car then bitching to everyone how you have to buy gas for it to work. People who complain that games are too hard, shouldn't play them, they aren't all meant to be chinese checkers or yahtzee.
EQ was too hard? Then you plain sucked at it. Accept it, go home, pull out one of the millions of 3D FPS's, and use a god cheat. Or better yet, pay a prostitute to tell you how large your dick is, because things in life have value equal to the effort put into them, which is why gold costs more than shit, and why they don't give nobel prizes to people who sit around drinking beer.
If it wasn't a fun game, why did/do so many people play it as much as they did?
Just tired of people expecting everything to be mindlessly easy. Life is meant to be a challenge, that's why so many people die from it.
Most people here seem to be missing the point.
:(
EQ/Vanguard are not for people who enjoy playing mmorpgs, like they enjoy playing other games, or for people who play them like glorified IM clients. These games are for the people who actually enjoy the challenge, enjoy the fact that it might take hours to get a reward, and instead of hating the process, count it as an effort towards building a character they see value in.
This is like saying MGS 2 was too hard because you couldn't play it like Tetris or Solitaire, they are totally different types of games. In WoW, the actual work done by the player is minimal, with low risk, and even unskilled/casual players (which is a huge, HUGE market) can compete evenly with the hardcore players. They are actually different games, and the problem until now has been trying to expand the market with new unskilled players, while still keeping the hardcore tier-1 dragon-slayers with server-uniques which are critical to the game, like the old FoH and LoS guilds were to EQ, setting an inspiring ideal for the rest of the players to follow, part hero-worship, part social-hierarchy.
My point is they are different audiences completely. Trying to put them in the same game is difficult without either pissing off the casual players, or letting the hardcore players reach the "End". WoW tried, and got an assload of casual players, but most of the hardcore players I know have left, doing cameos whenever a new dragon comes out, and otherwise actually getting on with their lives. The only hardcore players in WoW now are the compulsive "Ok now I want armor X and horse Y so I look cooler" until the next patch comes out with new armor X and horse Y.
Basically, I miss EQ
Final Fantasy 1 for the NES: Long game with lots of little details and weapons. Played better than most genesis games.
Phantasy Star 4 for the genesis. Not many played it, but it was long, complex, played nearly like an early ps1 game. Decent storyboard cinematics, and best gfx in an rpg for its system.
Final Fantasy 9 for the PS1: plays like a PS2 game for sure.
Ultima Underworld and The Summoning: both played on a 286, UW was a first person doom-dungeon trip, the summoning was a colorful and complex wizardry clone.
These aren't just games that push the systems, these are also games that put design before production, ie. concept above code, with consistency and playability above quick flashy gfx features (remember mode 9?) and uncontrollable cutscenes that are added because they look good in demo videos.
Castlevania:SOTN gets the other side of this award tho, for making the most crazy fun, but technologically backwards game this side of tetris plus.
XFS has issues that go version by version. I've had volumes work perfectly for months suddenly start spitting out I/O spam after a simple kernel upgrade. My guess is poorly applied patches, as many xfs kernel patches are added downstream by a distro or kernel contributor (MM/gentoo). just my 2c, YMMV.
if solaris is an option go zfs. hands down best fs if you can run it, incredible flexibility and scalability.
also, you mentioned something about burning to dvd, filesystems won't really help with that, i'd look more into taring your filesystem/ fs segments into disc sized segments, then making extra par2 files for error-resilience.
really, backing up 2tb of live data is a f*ing nightmare however you look at it, usually when i reach that hurdle i just build another machine, copy over active data, and put the old box in the closet, a sort of living backup if you will, if i ever need to go back to it. at the cost of hd's now, especially with removable sata chassis's it's the only way to handle the sheer size of data you'll be dealing with.
reiser or jfs are both solid for this kind of work, with large file and volume support. personally i swear by reiser for my 2tb volume, and have had no problems so far, although there is a minor speed penalty when working with several multi-gigabyte files at once, something to do with shared fs locks/mutexes i'd imagine.
OTOH JFS is quite stable, and though it has less of the elegance in feature set I find in reiser, tends to make up for it with enhanced ruggedness and its handling of large volume/files.
Really can't recommend anything else, as you say, reiser4 is still untested for reliability imho, xfs has issues that vary from kernel to kernel, and ext3 appears quite primitive in comparision, although its journaling seems comparable to the other choices.
JFS if you need the speed, its dead fast in large scales, slower with small files, otherwise Reiser3 is an excellent all-round performer.
ahem, my point is the emotion and overall meaning come across better in the original japanese.
No, it is horrendously confusing, but that's because it's complex, and doesn't take the time to explain everything for the slowest kid in the class like american media. Takes a few passes to get most of the meaning, but I didn't understand most of the plot of the second season till i got a new fansub of the ending ep.
In Asia, being smart is something to be proud of, like being attractive, vs. here where it's something to hide so you can seem like everyone else. It's a different approach to social interaction and hierarchy, and took me completely off guard when I first noticed it, compared to growing up in rural indiana and tn.
uhh, yes?!
on another note, i've given up on english translations. GITS season 2 had atrocious voice-dubbing, and without the original japanese the series loses so much of its meaning. Hearing a anti-tank helicopter pilot sound like the cocky "Mav" from top-gun destroys the ambiance of what is meant to be a complex, thoughtful series. It's like trying to watch a ferrelly brothers movie dubbed into german, it's stupid, AND it doesn't make any sense.
I have little hope for AD dubbed into english either, a lot of anime japanese is too complex to easily translate between cultures, and we don't exactly have attention spans over here.
security: depends on your config, but without a pdc, cert authority and a good bit of other addons, windows networking doesn't have the real framework to support real security. Also, while the permissions model is functional, it is not always consistent, and often needs to be configured by hand to maintain proper security levels. For real high security applications, either a windows pdc or solaris nfsv4 would be needed, but for common working environments nfs is generally more secure, and more easily securable. Part of it depends on your sysadmins skillset I guess.
NFS is faster, much, in actual access, latencies, transaction times. SMB requires full tcp connection requests per access, which allows for high transfer rates of large sequential files, but means for a large number of small files, or multiple seek/operation accesses of large files, SMB is pretty damn laggy. There are benches of this. NFS uses a more complex, low-level udp to kernel inode system that allows for a far lower latency time. Really something you have to see to understand, I have a 2tb raid5 on an 8-pt areca pcie x8 which can fill my gige connection, and nfs is much faster than local file access vs smb which has minor transaction lags whenever the sequential stream has to be seeked or restarted, or new files are opened.
The real bottleneck here is the protocol, and kernel-mode nfs is much lighter and thinner than user-mode samba, but you really can't understand till you try it.
I agree, especially about power and heat.
My holy grail is to find a good system to build a mATX server out of, with gigE and possibly raid5 on 5 drives. Alas so far I've never managed it, although it is possible by mangling an antec aria.
I still dream though...
k, going by points:
NFS only for "mac/linux"? What about Solaris, *BSD and Microsoft Windows?
Yes, but considering the OP doesn't sound like he knows the basics of raid or sharing and is looking for a smb solution, WTF is the chance that he's running solaris 10 on an SF25k??
NFS faster? That depends very much on your setup.
Real world, GigE, as long as all the files are not less than 5mb NFS blows smb away. The latency is less than a third, transaction time less than half. SMB starts a new connection each file, and seeks are synchronous. Performance sucks unless you're just streaming files sequentially. Try it and see.
NFS is better? In what way? NFSv3 is a security hole, whilst NFSv4 is best implementented on Solaris.
Funny, I'd say Windows is a security hole, smb rides on the already crippled windows networking authentication system, including the broken kerberos, and unless you have a machine to set up and money to pay to run a PDC, don't even hope to have a secure server. Basically a domainless windows network is open, no matter how you try to secure it. NFSv4 is best on solaris, no question, but any version is better than any version of smb, short of samba to samba on linux boxes only.
Quite simply, you know even less than me.
0h, pwn3d by t3h l33t m@5t3r! 1 @m f3@r3d! Plz d0 n0t pwn my w1nd0wz b0x3n w/ ur3 l33t h4x0r sk1llz!
Actually I agree, but it's usually not practical. Linux software raid is ub3rl33t, but relatively annoying to boot off of. I used to set aside small partitions on all my raid drives to boot and root from, with the data going on the main raid partitions, but its not fun, nor elegant.
Sorry only read half your article the first time. Started out on slack. Good times...
/proc/sys/net/ipv4/ipfrag_high_thresh and low_thresh, my values are 256k and 192k respectively.
use the async,vers=2 line in both fstab and export options, and the size options. There is also an issue with datagram defragmentation, which is fixed via
Mostly though I'm pretty sure youre just running in sync mode, which is unGODLY slow at 1k rwsizes. Set that to async and preferably vers=2 and you should be screaming.
And yes, trying to work this out blindly on the web is a nightmare, I spent a half a week playing with settings and experimenting the first time, and hope never to do so again.
Best of luck!
Actually yes. I went on an nfs tuning jihad a year ago. The results varied, sometimes I got a huge improvement, sometimes none at all between different boxen/configs. This is for linux only btw, tuning solaris for nfs is a totally different monster.
http://nfs.sourceforge.net/ Gives you some info
Most of the tuning faqs i went through were crap and elementary once you get to gigE an such. My current settings are simple:
mount options:
rsize=8192,wsize=8192 : Best I've seen so far, and works well with jumbograms, have experimented with everything between 1024-32768 in both udp and tcp.
noatime
export options:
async,vers=2 : If you just need speed, big improvement because mount tends to ignore async in negotiation a lot
My condolences on your recent loss.
Couple questions:
1. SMB only? NFS is faster and plain better, but only for mac/linux.
2. Noise/size/power constraints.
3. Price.
SMB only, moderately cheap, quiet and small, go for a teraserver from buffalo networks. Easy to setup, runs decently, 4x250 drives that can be raid-5'd into a 750 array. Costs about $800.
A good midlevel solution is an nforce4 motherboard, with 4 250 sata drives, total cost around $600 w/ cpu mem, etc. You need a decent case though, and it will be noisier and louder. Plus side is better performance, full customization, and ability to use it as a router or such. You will have to configure it yourself, and likely throw windows on it because the nforce raid support is tricky on linux for a novice.
I use a heavier 2tb solution myself with a HW raid card, but for most purposes a sw raid is better, and the performance difference is almost never noticable. Personally I recommend the buffalo if you don't need nfs, just for the size, quietness, and convenience.
I'm not trying to write-off chip speeds, but as a programmer I'm aware we can't just count on the fact that this bloated, single-threaded program/game which slugs around now will work fine 1 year from now when the processors catch up.
Second, multi-chip cpu's do work, the gpu is essentially a graphics slave to the primary, specialized for its tasks, with access to primary memory, and using specialized (tho with need of improvement) mechanisms to offload work from the cpu. TCP offload adapters are similar if not the same. How are multi-chip processors dying? Even the new physics addons are attached via high speed interface. The new line of high speed busses and interconnects are easily capable of handling the data and latency. How do Opteron's share each other's memory and IO otherwise via a simple HT link?
Ok, Yonah blows my intel idea, but my point was that Yonah wasn't a blind "design it first, then just try to keep shrinking it" like prescott.
Or, make a version of an ALU that can SIMD 16-32 similar operations at once, and schedule accordingly.
Finally, no, there is almost no way we could keep a 1000-thread chip full today. That is not a flaw of the chip, or concept, but of our current programming methodology. Are you honestly telling me there is no way to change the language, or design guidelines to unroll loops in parallel? Assuming only 200 are going to be running at any time due to memory/IO/waits, you have less reason to be so focused on branch prediction or cache misses. So a thread misses a couple cycles waiting on memory, the penalty is miniscule. Have 2 branches to choose from? Choose both, and discard the unused one. For loops can be coded as dependant, or independant, or in the case of DSP like functionality, unrolled with the pointers tracked automatically, parallelizing the operation completely. All this could be done if not today, than soon, without waiting for a 200x increase in clock speeds, which may or may not happen, and with few or none of the drawbacks. All the eye candy in modern os's? Free of charge, because that is just processor power that would be wasted otherwise. Who needs a gpu, your cpu can do that as well or better with an internal geometry unit, with no need for seperate memory.
The point is once the individual operation cost drops because of massive parallelization, the entire way of looking at programming and computers in general can be changed so the current high-revving, but stop for roadbumps viewpoint can be replaced with a steady convoy of trucks metaphor. Every instruction your computer executes is not dependent on every instruction executed before it, that is a restriction placed on computers by us, for debugging purposes and because multi-threaded chips were more expensive than high speed chips until recently, a product of CMOS fabrication technology. We still use processor interrupts for similar reasons, even though they are a huge performance hit unless done properly, and have been removed as far as possible from modern software and hardware designs.
Single threading is just a legacy frame of mind, because debugging dozens of threads without the right tools is hard. Once we develop the right tools, why in god's name would we want to run 1 thread at a time? Just imagine massive multithreading as the next generation of the superscalar architecture used in current chips. Take it to the next level, and blur the lines between current threads and a superscalar scheduler instead of handicapping yourself by forcing dependency scheduling on chip by dedicated circuits that have very little idea of the actual dependencies and execution flow, and less ability to flexibly reschedule for efficiency.
a: I think I misspoke. When I said that at smaller feature size, resistance goes down, I was also considering leakage as a failure of resistance. You're right, the current 90nm designs do use less power, the amd design in particular because it uses SOI to compensate for increased leakage, while I don't believe intel has soi on its chip line yet. At these scales, execution tends to matter as much as size, and my earlier point of blindly scaling down in hope of finding more gains from the magical process shrink becomes much more of a challenge.
2: Also, in a 1000-thread chip, not nearly all the parts of such a chip would have to be replicated. Much of current superscaler design relies on scheduling for as efficient usage of pipeline segments as possible, to allow for the maximum chip usage. This same approach could work, by turning l1 cache into an effective register file, and simply having a part of the chip whose role is to schedule prioritized register sets to the requisite resources. At the extreme this could even allow decoupled pipelines, such that the decode, memory load and IO intructions are executed in a primary stage chip dedicated to preprocessing and high wait state instructions, then passed on via HS interconnect to 1 or more secondary processors to perform the actual arithmetic, even allowing whole chips to perform the ancilliary functions such as the sound or GPU today, while being tightly coupled to the memory and processor state.
My point is that from this point on, threading will scale much faster than clockspeed. Even now, it is easier to make a second core than to double the clockspeed for the faster processors, and unless the leakage issue from tfm is solved soon this won't change.
Plus, once you have the right programming language support, with auto-parallelizing iterands, and self-dispatching async subroutines, who needs a fast chip, the actual instruction pointer, the current limiting factor, becomes meaningless, with all actual work being done parallel automatically, dependencies and resource sharing solving themselves by language design. A 1Ghz multithreaded chip can be as effective as a 4.0 Ghz prescott today, without even including the specialized instructions (SIMD, fast fp) that can boost actual efficiency through the roof, and be compiled in as static asynchronous subroutines dispatched parallel to the "main" thread.
The unfortunate corrolary to:is:
Which is why the P4 prescott, while a marvel on the drawing board, is pretty crappy in reality. 90nm technology has largely been an attempt to find a happy medium between higher capacitance and lower resistance, both of which limit speed. The current "nucular age" of chips is a direct by-product of ignoring the drop in resistance until it was too late.
Also, at 4+ Ghz an current-induced EM field has many of the properties of a microwave beam, which can resonate, and essentially self-focus on any imperfections in the semi-conductor structure, essentially burning small holes in the chip, or causing signal noise unless perfectly grounded (which in itself causes inductive leakage). This is why intel and amd have speed-bins, because the chips with the fewest imperfections are able to perform at the highest clockspeeds without thermal or electric failure.
My point is, the mega-hurts race, even assuming one or more miracles of metal-oxide chemistry, is ending. I look forward to the multi-proccessing race which seems to be heating up, as a long-postponed, but neccessary next step. The sad obstacle holding back the day of 1000-thread chips has been programmers complete lack of willingness to move beyond the single-threaded debugging paradigm. As one myself, I understand why it's seen as hard as it is, but consider it more of a viewpoint shift, rather than an insurmountable increase in complexity. New languages/language changes will happen to simplify threaded programming, and new mechanisms like auto-synchronized data structures, self-unrolling iterands, and integrated message-passing stacks will replace old-standbys. The mega-threading doomsday scenario will fall along the wayside with other past programmer nightmares such as the death of the goto loop and the loss of direct memory access in java and higher level languages, left only as subjects of nostalgia.
Clockspeed is dead, long-live multi-threading.
Hah! We of the pastafarian faith all snicker as you infidels again try to measure space not knowing that his noodly appendage has changed your observation to a space-time vortex.
Just as the bones of dinosaurs and the stars in the sky were placed by our noodly master, so is this great work of his doing.
Avast ye ignorant dogs! Worship ye great master and his wee midget. For he be a harsh mistress, and his noodly wrath shall send ye all down to Davey Jones's Locker!
while lawyers otoh, get paid by the hour. sit back and grab a beer, this fight ain't going nowhere.
seriously, it's like the cold war, it's against lawyers interests for either side to win, endless escalation is killer for billable hours. this kind of thing has been happening in every field of industry, blame the US for producing way too many of the vermin.
the pirates had kalashnikovs and rpgs, stop watching so much tv.
My apologies.
I hope you like Natural Ice(tm).
True, but I've heard of this kind of thing happening quite frequently from my friends in the ahem, military equipment sector.
Not that they say it happens to them, but the stories are ridiculous, with tests designed so they can't fail, or so failures are marked as partial successes, etc, because the project cannot have any black marks against it till acquisition... after which the govt will gladly pay to upgrade baselines to fix the flaws over the next decade. Check fas.org, but the first sparrow missle, the first line of tomahawks, b1 bomber, osprey, bradley's, even the proposed missle shield, all were/are acquired with obvious, mission-comprimising flaws that cost billions-10s of billions per project to fix. The problem is the acquisition system, especially congress's oversight, doesn't have an independent verification mechanism to prove that said equipment works within required parameters, and anyone who tries to say anything generally gets discharged from the military for going outside the chain of command and "comprimising the integrity of a classified project", even if the congressmen have clearance.
So if you were ever curious why so many ex-military officers found surprisingly comfortable jobs in the defense sector, theres an idea.
The corruption in the military-industrial complex goes beyond anything we can imagine in the private sector. Actual results being valued far less than pork per district works great in politics, but tends to hurt 2 politically defenseless groups, the taxpayers who fund these nightmares, and the poor troops who end up wondering why they have to bolt sheet metal onto their hummvees while people are shooting at them.
I'm sorry, did you read your argument?
If we do not have oil to use, as we do now, how have we not run out of oil. When I say "oh im out of milk", I don't mean the last cow has died and no more exists in the world, I mean I have no practically accessable milk until I resupply from the store.
Economically useful oil running out is a serious threat, because, well we kind of depend on it right now, hence the point. Technically the world is producing more oil as we speak, but so slowly and unreachably that it effectively does not exist to us.
Being philosophical about the existence or non-existence of a common economic commodity is like trying to prove God exists so you don't have to go to work tomorrow.