I’m at home with nothing to do. I’m not complaining. Amey gave me a heads-up for the rain just as I was leaving the house. I did an about-turn and walked right back in. Pacenet, down since 8:30 yesterday night, finally started working at 1:30 in the afternoon. I think Pacenet needs to be put under the scope.
Right off the mark, I would say this – When it works, Pacenet is the ISP to beat. When it doesn’t… thats another story. The problem is – its not working; rather frequently at that. If you want the background on the tiff between Pacenet and me, search this blog.
First off, lets see their hardware. Pacenet has built an incredible WAN that stretches across Mumbai. Of course, the LANs that make it up are rarely bridged. Why? Because the LANs are the responsibility of the LCO – Local Cable Operator. The mess that is found in the cable television sector is perfectly mirrored in Pacenet’s LANs. Officially –
We do not support usage of Pacenet’s networks for purposes other than connecting to the Internet.
If you can, use the LAN. If it messes up your system, don’t come to us.
And thats that.
The software is brilliant. Pacenet has mostly speed and time based packs. It utilizes RASPPPOE for authentication, billing and control. The mess begins here. The Point-to-Point Protocol (PPP) was developed in the Unix era – primarily to exploit copper telephone wires to transfer data between two Unix terminals. This was when microcomputers and workstations were reaching a sustainable density. Today, all OSes have PPP implementations, be it win32 or Linux or OS X. This includes the traditional PPP used for dialup and PPPOE – PPP Over Ethernet – used for running PPP services on LANs/WANs. But Pacenet skips over them and installs a third party implementation of the PPP protocol, RASPPPOE. Is it necessary? Over and above this, the Pacenet Dialer installer has an option for installing yet another PPPOE implementation. Now, is it necessary?
So, where do the problems begin?
With the service structure offered at the customer premises. The LCO is your intermediary, whether you want him or not. The problem starts with selecting the pack. Each LCO has his individual arrangements with Pacenet. And each offers only select packs in his area. So if a scheme is available in your friend’s area, it may not be on offer for you. The billing is unsynchronized. Its the LCO’s job and you are out of luck if he slacks off.
For hardware problems you are supposed to call the LCO. In turn, he forwards it to a technician on his contract. When the tech arrives, is another story. However, this is a clearly delimited area. No complaints here.
The problem is in the software. Errors bearing tags numbered 25xxx. Random things like POP services timing out or websites not loading. Unreliable PPP services and PPP services not offered. The first part of solving the problem involves fixing the blame on someone – Pacenet or your LCO? And it is the most vexing part. For the buck-passing that occurs is astounding.
Conclusion? Pacenet is only as good as your LCO.
So I think I’ve done a rant. Is there a solution?
- They should clearly delimit their AOs – Areas of Operation. Call us for this. Call your LCO for this. It is already existent, but it should be further refined.
- Throw open their LANs. Bridge the LANs. LANs are a technical asset, not a liability. Pacenet should allow the customers to work the system. People using a LAN actively will be motivated to look after it and report problems. It will also add more value to Pacenet’s services.
- Reduce their dependence on a specific implementation of PPPOE. And make their PPPOE services more reliable. Having a daily average downtime of more than an hour is simply not done.
- Increase the TQ – Technical Quotient – of the LCOs. They may know a lot about running Cable TV systems, but LANs and Internet Services are on a different level altogether.
Did I miss anything?