Slashdot Mirror
Linux 3.7 Released
The wait is over; diegocg writes "Linux kernel 3.7 has been released. This release adds support for the new ARM 64-bit architecture, ARM multiplatform — the ability to boot into different ARM systems using a single kernel; support for cryptographically signed kernel modules; Btrfs support for disabling copy-on-write on a per-file basis using chattr; faster Btrfs fsync(); a new experimental 'perf trace' tool modeled after strace; support for the TCP Fast Open feature in the server side; experimental SMBv2 protocol support; stable NFS 4.1 and parallel NFS; a vxlan tunneling protocol that allows to transfer Layer 2 ethernet packets over UDP; and support for the Intel SMAP security feature. Many small features and new drivers and fixes are also available. Here's the full list of changes."
Just proves what a wanker you are, then
experimental SMBv2 protocol support;
This can't come soon enough for Linux clients. SAMBA already has SMBv2+ server-side support, with SAMBA 4 apparently even supported SMB 3.0. This is especially true for a high-latency connection through the VPN where the reduced chattiness of newer SMB protocols gives a nice performance bump.
You can post all day & all night about how NFS/CODA/GlusterFS/etc./etc. is better, but at the end of the day the CIFS protocols are supported by every Windows machine out there and should be supported by Linux too. Plus, if you are a free-software purist, then you could setup a 100% GPL'd installation with SAMBA servers and Linux clients, so it would totally make sense for the Linux clients to actually support the modern protocols.
AntiFA: An abbreviation for Anti First Amendment.
Signed modules? Yay for tivoization!
Proud member of the Ferengi Socialist Party.
They guy on First.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
kernel in c++? no? ill move on then,
Yes please.
Does it `Just Work' (tm)? I really want rolling snapshots ah la NetApp.
Sorry to be obtuse. Not much time for experiments.
Why does vxlan transfer L2 packets using UDP and not TCP? I have also seen this on other L2 protocols like L2TP and PPTP ... just curious ...
TCP has a feedback loop when packets are lost... So you'd have that at both layers, the actual session and the tunnel.
Its an engineering thing where if you embed a feedback loop inside a feedback loop, things will be OK if you're VERY careful but most are not and you'll make a lovely oscillator and just blow it all to bits.
Fundamentally, UDP doesn't guarantee delivery so its OK to shove it inside UDP, and TCP has its own repair mechanism so you don't need to guarantee its sub-layers, so its not like you're missing anything.
Finally it just kills performance because TCP loves big buffers for each connection so you need megatons of ram until you start dropping packets and letting TCP police itself. Which meanwhile results in horrific latency. But if you tunnel over UDP, you don't really need much of a buffer on the tunneler itself and you'll overall end up with better latency specs. So its cheaper and works better. Hard to beat that combo...
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
I haven't RTFA, but looking at the things you want to transport, it looks as if you're tunneling other stuff - potentially including TCP.
Tunneling TCP over TCP is generally a Bad Thing. The flow control of the tunnel and the flow control of the tunneled can interact in really ugly ways. By using UDP to create the tunnel, when you send TCP over that tunnel there will be only one flow control.
This is from the ancient days of "PPP over SSH/Telnet", when it used to be possible to get a shell account, but not IP access, from many "internet providers".
The living have better things to do than to continue hating the dead.
Is it finally ready for prime time? any one with experiences/horror stories?
When his defense asked, "Which computer has Jon Johansen trespassed upon?" the answer was: "His own."
At that point you don't need the reliabilitiy and retransmission features of TCP. Once you stack the layers up, TCP will take care of that anyway, without running it over TCP again. Think IP: unreliable datagrams; you put TCP on it and presto: reliable, ordered, everything. Run a VPN, and you do it over UDP, and end up with something like IP -> UDP -> TCP, and then TCP again does its thing, without a care in the world about the layers below. Same principles apply with this new things too. If your underlying layers are flaky, you can't make them less flaky by adding more TCP to your cake. In effect, you make them even more flaky as each TCP layer tries to do its own retransmission and floods your line.
Question for religious people: where do unrepentant masochists go when they die?
The ability to boot into different ARM systems using a single kernel is kind of cool, but the need to do it is kind of scary. Is ARM not actually a single instruction set architecture, and if so, what is it?
Windows is up to 8. Obviously, it is more than twice as good.
I forgot to mention one real life situation where UDP over TCP does not work.. UDP conceptually works pretty well with real time live streaming. "Here's 5 seconds of audio of the ball game". 5 seconds later, if lost, that packet is meaningless, don't bother re-sending it, the RX will just output 5 secs of silence or whatever. TCP does not understand that at all, so you can get serious problems with live streaming if you try to stick that inside TCP and experience significant network congestion. Buffers get bigger until they pop, "live" becomes randomly "tape delayed" based on recipient... Also TCP doesn't understand variable bit rate, so its ideas about buffer allocation bear little resemblance to what the codec actually wants to do.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
now lets work on making linux work on a desktop/workstation;-)
Works quite well already on my workstation. Any particular areas of interest where it needs improvement in order to work?
Super Monkey Ball 2.
And why should I, as a *nix user, care about what windows supports.
Because you may end up having to integrate the *nix that you use with the Windows that an employer, client, etc. uses.
The Kernel Newbies site isn't accessible for me, clearly they're using 3.7. :)
Nice discussion! I have run OpenVPN over port 80 TCP in order to get past a firewall. It worked but a little later I tried port 80 UDP. It worked better. I was happy to discover an unblocked UDP port for my needs.
Ray Seyfarth, ray.seyfarth@gmail.com, http://rayseyfarth.blogspot.com
Presumably the reduced overhead of UDP was considered by the developers to be a worthwhile tradeoff against the convenience and stronger guarantees afforded by TCP.
ironically enough the problematic area was games and the linux detractors never brought it up. Let us see what Valve comes up with.
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
UDP port 53 or port 500 are often unblocked.
UDP port 53 might be redirected to a local server in many places though.
TCP tries to (and usually succeeds in) trasfer a stream of bytes reliablly and in the right order over an unreliable packet based system.
To achieve this two things have to happen
1: the sender must resend lost packets
2: the recipiant must hold packets after
However there is no way for a sender to determine if a packet has actually been lost or just delayed. So the sender must use a timeout to deem a packet as lost and retransmit it.
Now suppose someone builds a tunnel using TCP and runs TCP over that tunnel so your stack looks something like.
Application
TCP (inner)
IP
Tunneling protocol
TCP (outer)
IP
underlying network
Everything works fine as long as no packets are lost. However when a packet is lost by the underlying network the outer TCP layer freezes all transmissions through the tunnel until it has retransmitted the packet. During this time it is likely that the innner TCP layer will also deem the packet(s) lost and try to retransmit them (possiblly more than once due to the auto-adjusting timeouts used by TCP). Then when the outer TCP does recover it will deliver both the original packet and the retransmission from the outer TCP. This behaviour is very similar to what happens when a network is congested and make cause the inner TCP to unnessacerally back off the data rate.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
I agree with your comments but want to add a clarification to your last paragraph for the benefit of all /. readers.
TCP needs enough buffer that it can hold a copy of each packet sent until it receives an acknowledgment because it may need to re-transmit the packet if it gets lost. Once the packet is acknowledged as having been received, TCP frees up the space. As such, there is a straight forward way of computing how much buffer TCP needs if you want to fully utilize the bandwidth of the bottleneck link along the path.
The amount of buffer is twice the round-trip time multiplied by the bandwidth of the bottleneck link (aka, "the bandwidth delay product"). More that this is a waste as it won't be used. Now, the effective round-trip time will increase if you have packet loss along the path. And congestion in the network (possibly made worse by the buffer bloat the previous post points out) will also increase the round-trip time. And the bandwidth of the bottleneck link is probably not directly knowable by the end hosts (although it can be reasonably estimated). Thus the amount of buffer space can be estimated a priori.
Note: you will still have to have this much buffer space to achieve full performance even if you tunnel TCP through UDP. It is just that you won't have to have much more than that amount. Also, having inner and outer TCP connections result in them fighting against each other, as you point out. (That is why it is not a good idea to tunnel TCP over TCP, not primarily because of buffer concerns.)
Note: you do need to have sufficient space for the inner TCP or it won't be able to operate at full speed. But you won't need double the space as you would with TCP within TCP (assuming you could solve the fighting among themselves issue).
it will deliver both the original packet and the retransmission from the outer TCP
That should have said
it will deliver both the original packet and the retransmission from the inner TCP
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
TCP needs enough buffer that it can hold a copy of each packet sent until it receives an acknowledgment because it may need to re-transmit the packet if it gets lost.
Thanks for the explanation!
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
For many classes of device the choice comes down to either propietary firmware in a rom on the card or propietary firmware included with the operating system. Do you really belive the former is better for freedom? if so why?
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
"Do you really belive the former is better for freedom? if so why?"
Certainly it's better. Because once bought the device is static while the OS is not.
In other words: you don't want not to be able to upgrade to 3.8 just because the vendor dropped support for your otherwise perfectly working device.
There's plenty of jobs to get picky about the ones you choose.
Unless you happen to have grown up in an area where there aren't plenty of jobs and need a job to save money so that you can move to where there are plenty of jobs.
That wouldn't be trolling, because Slashdot is a largely pro-Linux community. If he went to an MSDN forum and posted that, then he would be trolling. Whoever posted this is trolling because he/she knows that Slashdot is pro-Linux.
Apparently wizard is not a legitimate career path, so I chose programmer instead.
Does: "MD: TRIM support for linear (commit), raid 0 (commit), raid 1 (commit), raid 10 (commit), raid5 (commit)"
meen that if I run a software raid-1 on sdd disk, then Linux can do Trim on the disks?
The kernel doesn not support AD, you should look at Samba 4.
New things are always on the horizon
IMHO, this is one of the more important features added in 3.7. People will hate me for saying it, but I personally love NAT and was really disappointed when initially the line was "we will never do ipv6 nat in the linux netfilter components".
But, thank god someone came to their senses.
1. thoroughly wash your bedsheets (or get new ones)
2. throw out your mattress, and any carpeting underneath
3. thoroughly vaccum the frame
4. buy new matress
5. learn personal hygiene.
6. most important: lose the neckbeard
It wasn't very long ago that one of the machines I was looking after was 300MHz and mostly doing a decent job as a small business mail server and web proxy. Handling large mailboxes (6GB+) in webmail is the thing it couldn't do well and the solution was a system with more memory, but the actual clock speed, even so slow, wasn't really a problem (the replacement that is ten times the speed is not ten times as effective for most tasks).
A 1GHz ARM system with bucketloads of RAM (16GB is cheap these days) would make a pretty decent internal webserver, mailserver and web proxy box that you could stick on a shelf and not care whether the room is airconditioned or not - it could fill the role of something three times the speed with little or no obvious reduction in performance for a lot of applications.
SUSE offers up an unsupported work-around: "If read-write access to an ext4 file system is still required, you may install the ext4-writeable KMP (kernel module package). This package is available in the online repository "SLES11-Extras" and contains a kernel module that provides read-write access to an ext4 file system. Be aware, that this kernel module is unsupported." (https://www.suse.com/releasenotes/x86_64/SUSE-SLES/11-SP2/#fate-311111). Clearly, SUSE is going with BTRFS instead of ext4.
TCP also need to buffer on the receive side, since it guarantees in-order delivery. If a packet gets lost then every packet after that gets through gets buffered up until the lost packet is retransmitted/received. Also, if the odd packet gets delivered out-of-order the the a few packets need to be buffered to sort them back out again.