Ask: Persistent issues with PTCL Broadband DSL service.

I have been facing two slightly related issues with PTCL Broadband DSL connection consistently ever since I started using the service.

I am using the de facto SmartAX MT880 DSL modem PTCL ships out as CPE with their broadband package along with YCL CPF105C ADSL splitter device. The modem is set up in a common household setting — the wire from the land-line sockets is plugged into the LINE port of the splitter, the only telephone set in the house hooked through with a wire to the PHONE port of the splitter, while the MODEM port connected to the modem through another cable. The internal configuration settings for the modem are exactly as PTCL recommends with, notably, VPI/VCI ratio under WAN Settings set to 0/103. Encapsulation is configured to LLC, with connection and wan types set to PPPoE and PPP, respectively.

What are the issues I am facing? The modem de-syncs occasionally. That’s issue number one. The second issue, which is more frustrating, is that while the ADSL link remains established, connectivity breaks down, comes back, breaks down again, and so on and so forth. The latter behaviour manifests itself a lot more often than the former, although at times the former logically follows the latter (but not always and not most of the time). With the issue with failing DNS that is not uncommon with PTCL DSL, I should like to clarify what I mean by “connectivity breaking down”. The default gateway for my PVC-0 link is always 116.71.0.1. Therefore, when I confronted issue number two the first few times, I figured if PTCL’s backbone connectivity is dead when my connectivity is dead, I would still logically be able to get to the gateway without any loss of packets. So, ever since, I have made it a habit when I log in to the system to open up a terminal and keep a session running in the background that is consistently pinging the gateway. When the connectivity breaks down, the ping to gateway breaks down as well (and vice versa). That outright rules out faulty DNS as one of the possible causes of the issue. The ping to gateway simply breaks.

On some days, it would just work fine–the ping to the gateway would run smoothly without so much as a hitch. On other days, it would either run fine for a while and then start breaking off, or start breaking off and on from the outset. That breaking part is most annoying, as there is no fixed pattern to the behaviour, and once the connectivity breaks, all my sessions naturally get timed-out without my realising what has happend not until it becomes perceptible. Make the break-ups more consistent, and you end up getting really frustrated, because you just can’t keep a session open with any other host for long without breaking off or timing out.

I have talked to PTCL support folks–but you know how support is. They seem to suspect there is noise in my phone line or the ADSL splitter is faulty. I have ruled out the latter by smacking in the old ADSL splitter I have from my previous DSL provider, Cyber.net. As for a noisy phone line, I am not certain. When I had DSL service from Cyber.net, I never faced any of these issues. Even during rain, when I couldn’t hear the tone properly due to excessive noise on the telephone set, the DSL worked brilliantly. It is only since I got PTCL DSL subscribed to that I have been facing similar issues.

If anyone reading this is using or has used PTCL DSL, I would like to hear your thoughts about and experiences of the service and any similar issues that you are facing or may have faced. Thanks.

Mid-week nightly Perl useless magic and fun!

Last night, I was sitting at my desk, watching text scroll by across an IRC session open in a terminal screen set in black, when my eyes came to halt at Pixelized on ##slackware on FreeNode soliciting help with a particular use of grep. To cut the rather overly technical story short, what Pixelized wanted to do was grok all text in a file between the keywords “X1” and “.bat”, inclusive. Being a long time Perl guy, I quickly threw two Perl one-liners that did pretty much what he had asked for. Both forms work perfectly accurately for my selected data set, but appeared to be slightly misbehaving against Pixelized data set. It was late, and I was already drooping with sleep, carrying a cracking headache, so I never bothered asking him for the data set. Anyhow, I thought I would share the two Perl one-liners just for the heck of it here.

perl -e 'while (<>) { if (/X1/ .. /\.bat/) { s/.*(X1.*)/\1/; s/(.*\.bat).*/\1/; print $_; } }' dump.txt

perl -e '$c = 0; while (<>) { if (/X1/) { $c = 1; s/.*(X1.*)/\1/; } if (/\.bat/) { s/(.*\.bat).*/\1/; print $_; last; } print $_ if $c; }' dump.txt

Blessed is I

… for I have an Internet connection at work that is so fast, so fast (and I can’t seem to be able to emphasize enough) it will blow your mind off. Some proof is in order:

ayaz@worklinux:$ ping www.google.com
PING google.navigation.opendns.com (208.67.217.231) 56(84) bytes of data.
64 bytes from google.navigation.opendns.com (208.67.217.231): icmp_seq=160 ttl=53 time=4228 ms
64 bytes from google.navigation.opendns.com (208.67.217.231): icmp_seq=161 ttl=53 time=4125 ms
64 bytes from google.navigation.opendns.com (208.67.217.231): icmp_seq=162 ttl=53 time=4031 ms
64 bytes from google.navigation.opendns.com (208.67.217.231): icmp_seq=163 ttl=53 time=4271 ms
64 bytes from google.navigation.opendns.com (208.67.217.231): icmp_seq=164 ttl=53 time=4270 ms
64 bytes from google.navigation.opendns.com (208.67.217.231): icmp_seq=165 ttl=53 time=4120 ms
....
--- google.navigation.opendns.com ping statistics ---
268 packets transmitted, 268 received, 0% packet loss, time 1151151ms
rtt min/avg/max/mdev = 1341.835/3478.865/4567.353/756.374 ms

Boasting average round-trip times of over three seconds and max round-trip times of nearly five seconds, boy oh boy, the Internet connection at work gallops like a Unicorn or what. Totally captivating.

On an otherwise completely unrelated note, isn’t it simply fascinating how people who know jack about networks pass off as highly skilled senior network engineers who happen to know the ins and outs of any goddamn network like they know to a questionable degree of accuracy how many hairs their beards are made up of? It sure is.

My best wishes and happy birthday!

Where ever you are, what ever you’re doing, I only hope you’re in the best possible health, state, situation. I wish you a happy birthday. I wish you all the success, happiness, and joy in life–for life’s too short, too cruel, too difficult. I wish you all the luck in life that can possibly be had.

Drenched memories.

“It rained heavily, and periodically for a little over an hour.”

The downpour, following an intermediate sand storm, was one that happened roughly after a whole year, or something to that effect. It came as a surprise, as with many other aspects of mother nature, but was, nonetheless, a moment to be cherished by us Karachiites.

Coincidentally, Shahbaz and I, while jumping off a local bus near our houses, were talking about the scarcity of rain in this part of the
country. The weather was a little temperate than ever with grey clouds covering the sky partially late morning today. It seemed to me that it would rain, but the eventuality was an unlikely one. Little did we know what we thought of was going to transform into a reality and to bump into our faces later the day.

“It rained, and rained, and I was completely drenched.”

During the downpour, I prepared tea for the family–something that I have been doing for ages–and left my cup on the main dining table after serving my mother. Having finished fixing myself a cheese sandwich, I noticed what appeared to be small black spots floating on the topmost layer of my tea. These were dirty drops of water that had somehow found their way in my cup through the ceiling window. I flushed the tea in the sink, and picked up the other cup lying safely in the kitchen.

“Few things are better than a hot cup of tea, with a cheese sandwich, on a raining day.”

I suppose it rained throughout Karachi. It had been a while, obviously.

(Note: I wrote this excerpt a couple of hours before midnight on the night of 18 June 2003. I consider myself lucky to have found it in the archives of the mailing list to which I posted during high-school years.)

Dual-Head: Sharing laptop’s desktop with external LCD.

I bought a second-hand 17″ HP LCD from a college friend. I got it to use with my headless Dell desktop box, but since it runs Slackware and I work with it remotely, I have the LCD now attached to the laptop as an extended display. Luckily, the ATI Radeon card on the laptop supports dual-heads. I have extended my 15.4″ display over to the external LCD, and, well, suffice it to say, it rocks. A couple of close-ups of my study are attached below. For Windows XP users who are frustrated with Windows not supporting taskbar(s) on extended displays, please take a look at Oscar’s Multi-Monitor taskbar. It is nothing like the native taskbar Windows has to offer, but it is the best I could find.

Additionally, I need to get Slackware to recognise the second display and move half of the desktop over. I have been playing with Xinerama and different configuration settings for Xorg, but to no success (to be frank, I have not yet had the time to do it at leisure). Xorg does enable dual-head support, but it tries to extend the display within the primary LCD, and in so doing messes everything up.

Of managers and wrong people at workplace.

I have been reading the book “Good to Great” for months now. It is such a wonderful read that I am intentionally resisting from devouring it in one go. I went through a few pages last night, and felt an itch to put the following excerpt on the blog. I typed it down from the book, so there may be unintentional typos.

Practical Discipline #2: When you know you need to make a people change, act.

The moment you feel the need to tightly manage someone, you’ve made a hiring mistake. The best people don’t need to be managed. Guided, taught, led–yes. But not tightly managed. We’ve all experienced or observed the following scenarios. We have a wrong person on the bus and we know it. Yet we wait, we delay, we try alternatives, we give a third and fourth chance, we hope that the situation will imporve, we invest time in trying to properly manage the person, we build little systems to compensate for his shortcomings, and so forth. But the situation doesn’t improve. When we go home, we find our energy diverted by thinking (or talking to our spouses) about that person. Worse, all the time and energy we spend on that one person siphons energy away from developing and working with all the right people. We continue to stumble along until the person leaves on his own (to our great sense of relief) or we finally act (also to our great sense of relief). Meanwhile, our best people wonder, “What took you so long?”

Letting the wrong people hang around is unfair to all the right people, as they inevitably find themselves compensating for the inadequacies of the wrong people. Worse, it can drive away the best people. Strong performers are intrinsically motivated by performance, and when they see their efforts impeded by carrying extra weight, they eventually become frustrated.

Waiting too long before acting is equally unfair to the people who need to get off the bus. For every minute you allow a person to continue holding a seat when you know that person will not make it in the end, you’re stealing a portion of his life, time that he could spend finding a better place where he could flourish. Indeed, if we’re honest with ourselves, the reason we wait too long often has less to do with concern for that person and more to do with our own convenience. He’s doing an okay job and it would be a huge hassle to replace him, so we avoid the issue. Or we find the whole process of dealing with the issue to be stressful and distasteful. So, to save ourselves stress and discomfort, we wait. And wait. Meanwhile, all the best people are still wondering, “When are they going to do something about this? How long is this going to go on?”

Makes me want to resign this very moment. Sigh.

Resource! (Random Musings #27)

The client complains, “Where is the resource? The resource hasn’t reached yet for testing.” The project manager frantically responds, “Our resource is on its way for on-site testing.” At another point in time, the project manager is caught writing, “I am aligning my resources for activities planned for today“.

Resource this. Resource that. I tell you, it pisses the hell off of me. I am a resource. Period. Expendable? Likely. But, nevertheless, I am a resource.

I don’t know about what any of you may think, but to me, referring to me as a resource is outright rude. Period. I seriously don’t know how I stand listening to people referring to me as resource again and again. Sigh. It is only a matter of time before I snap.