Recently posted comments

http://www.aosabook.org/en/llvm.html

Interesting, so this sounds like a different configuration than some bonding setups which appear to require only a single public IP address. I wonder if that's down to how the ISP configures their interfaces.

I suspect I could make a lot more progress here if experimentation didn't mean scheduling connection downtime of an unknown duration, which in practice means being physically present in a locked office building in the dead of night (for which honestly they Do Not Pay Me Enough™).

At any rate, thanks for the information.

codel + qfq can do even better.

The 5ms target of the overall codel algorithm is just that - a target.
Sometimes it's more, usually it's less, and with fair queuing (fq_codel) applied on top...

it can be MUCH less, especially where you need it. As in sub 1ms. Which should make a lot of gamers and voip/videoconferencing people very happy.

Also, for 10gigE installations people have been using 500us as the target,
which seems to work well. I wouldn't recommend changing the target delay for anything else at the present time.

Rather than theorize can I merely recommend people try this stuff out for themselves and ask questions on the codel at lists.bufferbloat.net.

I think the discussion is pretty pointless now...

So what I did was to set the primary address to a unique RFC1918 address, which was just used for management purposes when I needed to telnet to a specific router, and then to set the alias on each router to the same, shared, public address.

I then added static routes on each router to pass traffic for our public IPs back to the linux box where the bonding was done.

The WAN ports were configured with separate public addresses - a unique one for each router.

Bridge mode wasn't used - they were acting as normal routers.

I wouldn't like to say if the P660 is particularly good or bad - they were the free routers our ISP provided with the lines.

The security model for this use case is clearly very different from a server with several daemons running, or even remotely logged in users.

Thank you for that link. I hope nobody minds the thread-hijacking to ask a little more about this - it's not a topic that seems to have much Google juice.

With that setup, do I understand correctly that - assuming the ISP has the bonding set up on their end - configuring the TEQL interface as you have will work regardless of the connection method used? It looks like it's actually very simple so long as you know the secret sauce.

What I'm not sure about is the IP addresses on the routers. You say that they need to support two different *LAN* addresses; how are the WAN ports configured? Are they bridged or do they need an additional address?

Say for the sake of example that you have a /29 netblock, giving you 6 addresses once you've accounted for the network and broadcast addresses. You use one that's shared between the routers and one for the teql0 interface, leaving 4 available for other machines. Is that correct?

Incidentally, would you recommend the Zyxel P-660 series? I do wonder if a better modem/router might solve my periodic loss of ADSL synchronisation, and while I've tried two different models, it's entirely plausible that they're both fairly intolerant of noisy lines.

Yet we get 100Mb for $8 a month in cities.

Btrfs allows you to pool storage volumes together in a manner similar to LVM.

Although, I believe, it operates at a logical data/file system layer rather then block layer like LVM does. This allows you to do fancy things like stripe your metadata using a 'RAID10' and make your data 'RAID1'. Another distinct advantage to this is that your volumes don't have to match sizes or be of even numbers. So I can create a 'RAID1' array of a 500GB disk drive with a 1TB disk drive and a third 2TB disk drive. The file system just logically makes sure that any hunk of data is available on at least two devices. Newer versions of Btrfs allow you to rebalance and restripe your volumes on the fly in addition to being able to remove and add storage devices whenever you feel like it.

Btrfs allows you to break up your pool into separate file systems. Each with their own metadata and other such things in their own namespace. These divisions are called 'subvolumes'. By using subvolumes you can take easier advantage of features like snapshotting, different mount options, quotas, and the like.

If you look at the 'root' btrfs volume then subvolumes will show up as things that are like "/.subvolname". Although you can individually mount them and access them without first mounting the root subvolume.

So on my 'home system' which I use to house many KVM guests in addition to being my main desktop system I have, IIRC, 3 1TB drives combined with 2 2TB drives in a BTRFS storage pool.

The various file systems that I use shows up on the btrfs root volume as:
/.rootfs
/.homefs
/.imagefs
etc etc.

The initrd for Fedora is sufficiently btrfs-aware that I can specify that it use a subvolume to be mounted as '/' for my OS during boot up.

Now the problem with Anaconda that I have ran into the past is that is unless it's able to support the file systems I am using that I cannot seem to be able to use it to install or upgrade Fedora.

I would like it if I could just tell Anaconda to skip the whole disk formatting and mounting BS and just use something like /mount/target/ and let me figure out how to setup the file systems after it's done it's install. If I could do that then that would be the preferred method for upgrading my OS as I can use a live CD to setup the volumes how I want it and then just use Anaconda from there.

I haven't really looked into it too deeply right now and as far as I know the 'target' option may exist. I just am not that familiar with it. I haven't had time to download the Fedora 17 installer and play around with it since my original post.

I have a few VoIP installations for small businesses, and I generally don't want to do them if I can't keep latency under 50ms. It starts to get very annoying before 100ms (as in the "satellite link" effect).

That's why I think queue management algorithms should not be tuned for overused DSL links. While that may be relevant to those who are stuck with them, the buffers in your DSL equipment will kill your latency anyway. Already LTE connections have latency under ten milliseconds if you can avoid keeping them filled.

I agree 10 ms per hop sounds like almost an order of magnitude off. The people for which that is relevant won't be helped by this anyway.

This is all part of the C standard, so I doubt you'd see much variation in any compiler made in the last 15 years (probably more).