Multiple Gateways in v3

[ibholst]

Is support of multiple gateways still to be included in v3? Is there an estimated release date?

Thank you,

[lonnie]

Source routing works in v3. No estimate of delivery for x86, though. It is work in progress and people cannot understand the concept of software being late so we no longer give dates.

[jeff]

Source routing works in v3. No estimate of delivery for x86, though. It is work in progress and people cannot understand the concept of software being late so we no longer give dates.

Some people maybe, but the rest of us know it is always a moving target. At this point I think you are taking a bigger credibility hit by not giving updates than missing a date. I could care less about a date. I would just like to see an update every few days discussing how it is going. You are in beta test so there must be both closed and open issues. Those of us who have waited patiently would definitely like to hear about it when a feature closes and also be kept up to date on the show stoppers that are preventing the release. Simply telling all of us it will happen when it happens because a few pests have no idea how this works prevents anyone else from making estimates and contingency plans.

[lonnie]

I'm not sure what more I can say. The website lists the items we have in the WAR v3 release and it is in test. I have said we have units in our backbone that spans 100 km and uses 11 repeater sites to bring in various communities along the valley.

The thing being worked on right is driver tweaking. It does not have the performance we need and we are redoing some base modules to pick that speed up.

Sorry, but I am not going to give a running report of all the problems encountered and the solutions. You don't need that and it does nothing but take my time to report that stuff. Besides, that is development info, and not typically considered public information. It hurts me to be too open. I have had many chance remarks about a problem make a lasting impression on people. For instance I told one guy we had trouble with the new driver at a longer distance, and before I knew it he was telling everybody our driver could not do long distance. Clearly I would have been better not saying anything, but you live and learn. I am doing both.

I know you want to say it does not matter, but when you read your post it is apparent it does matter. You want to know when so that you can prepare your own estimates and contingency plans. That means that when we miss the date, you miss your estimate and you get angry and annoyed with us. I don't need that type of stress at this time, so I choose to avoid it.

The stress created because people are annoyed that I will not set a date is less than the stress of people annoyed because I caused them to miss their own estimates.

Use v2 for now. If it is not good enough, then you have to switch or wait. We are near the end of the project, so just sit back and be patient. It is coming just as soon as we are comfortable with reliability and performance. The features are already there and I am feeling great about reliability --> we had over 10 days runtimes on the main backbone. Everything got rebooted last night with a new test release, and they all ran over night, which is a very good start.

[jeff]

Unfortunately with a bunch of WAR boards out there V2 is not an option. My whole point was that I don't expect you to give us a firm date, but there must be some middle ground between "you get it when you get it" and a firm date that reflects a certainty that no software project will ever have.

I got burned badly by the VxWorks bridging problems. If the existing code allowed for more addresses on an interface etc. then I wouldn't have needed bridging. As it is I have bandaids in place that are keeping it running, not having any guidance at all makes it difficult to determine whether I should tear it down and replace it or just wait another week or two.

As a suggestion how about putting a sticky subject in the v3 forum that only you can post to. Make the first post a warning that the thread will be your only discussion of V3 prior to its release and then just list your milestones as you reach them with a guestimate of time remaining. That will help fill the information vacuum without taking much of your time. You can simple reference that thread rather than wasting time replying to individual questions.

We all know that you will get it to us as fast as is humanly possible and that none of us are under the same pressure with our individual projects as you are with V3. That said, this is our livelyhood too, and it wouldn't suprise me if you expected Gateworks to provide you with updates as they moved forward on your hardware design. Don't let the stress you are under blind you to the fact that most of us are very supportive of what you are doing.

If you interpreted my post to mean that I don't care about your schedule then I did not express myself well. What I don't care about is you missing your estimates, they are after all just estimates, but your estimates are a lot better than mine and at least we know your last one will be rock solid. If there is a major unforseen problem then you reset the clock, barring that your estimates should converge to the actual release date.

[lonnie]

I do understand where you are coming from, but let's just leave this as --> the code is in second alpha, with performance tweaks coming nicely. The code has already run trouble free for in excess of 10 days on the first alpha.

It is close enough that we can taste it. I would advise you to not be changing anything and just await the release. When we get the performance to where we need it, the release will be rapid, since we already know the kernel, etc is solid, as evidenced by the 10+ day runtime on the first out of lab release.

I appreciate the support being shown, and I am quite certain you will not regret trusting me.

[jeff]

Lonnie, it has never been a matter of trust. Your team does great work and having met most of you I feel very confident that no effort is being spared to take care of your customers. I also see where you are coming from and only hope we can meet somewhere in the middle on this. There have been several missed deadlines already and I was only trying to suggest that describing your progress and making some running estimates of time remaining would be the best compromise for both you and the rest of us. Letting a few pests stress you out isn't worth it. With any luck they will move to another platform and cut down on the noise factor for all of us. I could role my own system easily, but I wouldn't have Tony's drivers and in the end I would be worse off for it.

[lonnie]

The idea of a progress thread is OK, but that duplicates the website.

In case you missed it, it details the items that are planned and the items that are already working in v3 for the WAR boards. Seriously the last thing is the driver. On Friday we even established a VDS tunnel from a WRAP board to a WAR at each end of the 100km backbone. CBQ works. Firewall works, RIP works, OSPF works, NAT works, Bridging works.

We have some rewriting in progress to boost driver performance. Multiple ESSID works. WDS has not been tested, but should be OK.

[jeff]

I don't look at the hardware section as often as I look at the forums so I missed the upgraded description. I still think a progress thread is a good idea on several levels, but obviously its your choice. I'm a little surprised that the driver is the hold up. I would have thought there wouldn't have been that much of a rewrite from the VxWorks code which seems very solid to me.

[lonnie]

VxWorks --> Linux is not just a recompile. It is a rewrite. VxWorks is flat address space and Linux is protected and that means things are done in VxWorks that just are flat out illegal in Linux, thus much rewriting happens with the port.

This seems to be the issue. Most guys figure it is a small matter to simply take a VxWorks driver and move it to Linux. So, for all you guys that think it is easy --> It is not trivial and that is why the driver is delayed. Even when we have it to the point of working reliably it still needs VxWorks techniques re-coded for Linux to get the performance.

[jeff]

Wow, it has been many years since I did any VxWorks development so I didn't really think about the implications. I was hoping that the move they made to POSIX would make your task easier. Obviously not the case. It is unfortunate that most speed enhancements for one platform kill you on the others.

[ibholst]

Would it be possible to put the multiple gateway function in v2 for x86?

[lonnie]

There will not be anything new going into v2. It will continue to get patches but no redesign or addon.
Would it be possible to put the multiple gateway function in v2 for x86?