Consoles were the biggest troublemakers overall, accounting for more than 60% of the total questions posted on the website. In fact, of the top 7 problematic products consoles took the first three spots. Microsoft’s Xbox 360 was the most troublesome console, with 5,000 more questions reported than Sony’s PlayStation 3, which in turn had over 30,000 more complaints than Nintendo’s Wii. The biggest problem for Xbox 360 users was the dreaded Red Ring of Death, which signals massive failure of the console’s hardware (usually due to overheating), and was responsible for 45% of reported issues.

Meanwhile, the iPhone topped the list of troublesome smartphones by a wide margin. There were nearly 100,000 complaints about the iPhone, compared to just shy of 40,000 for the second place Samsung Galaxy S. Forty percent of the iPhone complaints dealt with battery life, while a further 15% were concerned with dropped calls.

Apple fared far better in the tablet department, however. The iPad WiFi was at the bottom of the list of tablets, and had less than a third the complaints of the leader, the Coby Kyros. The iPad also got fewer complants than the Samsung Galaxy and the Amazon Kindle, again by a considerable margin.

Did you have any of these problems over the holiday break? Let us know in the comments.

[Source: FixYa]

Royal Pingdom posted the top seven problems webmasters and site visitors alike may have encountered. Pingdom’s data comes from their monitoring of thousands of websites; this particular sample comes from 160 million test results over a 30-day period leading up to October 19.

‘Unable to connect to server’ occurred 62.4 percent of the time, where visitors simply could not reach the online resource. That was the most common problem, which Pingdom noted could happen due to network outages, server downtime, or possibly firewall issues.

‘DNS lookup problems’ only popped up about 9.71 percent of the time. Problematic DNS configuration usually causes this error, but in the case of the CA.gov domain, Federal domain admins at GSA in Washington inflicted the DNS problems for that domain.

Following these two top errors were ‘connection refused by server’, ‘timeout while trying to load the web page’, ’503 Service unavailable’, ’500 Internal server error’, and ’502 Bad gateway’. As Pingdom noted, some 80 percent of webserver problems were unreachable servers, DNS errors, and server load conditions.

Topics covered in the Analytics Forum include:

- Analytics Basics

- Tracking Your Site

- Your ROI

- Troubleshooting

- Urchin 5 Software

- Miscellaneous

For further discussions and questions, Google Analytics also has its own Google Group. For advanced implementation needs I would recommend the services of ROI Revolution or EpikOne (both have very in-depth knowledge of Google Analytics).

Comments

Tag:

Add to Del.icio.us | Digg | Reddit | Furl

Bookmark WebProNews:

Plugins are useful bits of code that add new or improve the existing functionality of your WordPress blog.

New plugins, and updates to existing ones, have been appearing thick and fast in recent weeks. So yesterday, I visited my list of installed plugins and updated a couple of essential ones. I’ve downloaded a lengthy queue of others which I’ll do when I have another spare moment.

I also added a new one which, as I subseqently discovered, caused havoc with the blog resulting in the blog being unavailable for about half an hour until I was able to fix the problem. I commented about it in a discussion thread on the WordPress Support Forum.

This is the first time I’ve installed any WordPress plugin that caused such a major problem. Having your blog vanish and be replaced by an alarming error text would give anyone a major headache.

In such situations, you have to employ a logical approach to troubleshooting:

1. Study the error message, if there is one, for clues as to where in your WordPress installation the error might be.

2. Think about what you were doing in your blog immediately before the error occurred. This is the first next step, so to speak, if any error message leaves you clueless.

3. If you just installed a new plugin, or upgraded an existing one, deactivate it and try and access your blog again. If the error ends, you’ve found the culprit. You then need to troubleshoot the specific plugin.

4. The same goes for themes – if you’re trying a new one, or installed an upgrade to an exisiting one, switch to the default Kubrick theme that ships with WordPress and try and access your blog. If the problem goes away, you’ve found the culprit and you’ll need to investigate the particular theme.

5. If you still can’t fix the problem, re-upload the core WordPress files again from the original files on your computer (you did keep them, didn’t you?), paying special attention to how your FTP program treats the files. For instance PHP files shoud be uploaded as text files not binary files. If your server uses Apache, check your .htaccess file to see if there’s any entry in there that might offer a clue as to the cause of the problem.

6. If any error message mentioned PHP anywhere, look for some help (and hopefully answers) from the hosting company from which you rent the space for your blog.

7. If all your troubleshooting steps fail, it’s time to ask the community for help by posting a help request in the WordPress Support Forum. You’ll need to be as specific as possible re the error including explaining all the troubleshooting steps you’ve taken to find a solution.

What’s your experience with troubleshooting WordPress errors? Are there any other steps that should be added here?

Comments

Reddit | Furl

Bookmark WebProNews:

Neville Hobson is the author of the popular NevilleHobson.com blog which focuses on business communication and technology.

Neville is currentlly the VP of New Marketing at Crayon. Visit Neville Hobson’s blog: NevilleHobson.com.

Lets take a look at a sample configuration.

Connecting Cisco routers directly via their Serial interfaces works really well once you get it running – and getting such a connection up and running is easy enough. You can use show controller serial x to find out which endpoint is acting as the DCE, and its the DCE that must be configured with the clockrate command.

R3#show controller serial 1

R3(config-if)#no shut

Failure to configure the clockrate has some interesting effects regarding the physical and logical state of the interfaces. Lets remove the clockrate from R3 and see what happens.

R3(config)#int s1

18:02:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down

The line protocol doesnt drop immediately, but it does drop. Lets run show interface serial1 to compare the physical and logical interface states.

R3#show int serial1

Serial1 is up, line protocol is down

Physically, the interface is fine, so the physical interface is up. Its only the logical part of the interface – the line protocol – that is down. Its the same situation on R1.

R1#show inter serial1

Serial1 is up, line protocol is down

While a router misconfiguration is the most likely cause of a serial connection issue, thats not the only reason for clocking issues. Ciscos website documentation mentions CSU/DSU misconfiguration, out-of-spec cables, bad patch panel connections, and connecting too many cables together as other reasons for clocking problems. Still, the number one reason for clocking problems in my experience is simply forgetting to configure the clockrate command!

Add to Del.icio.us | Digg | Yahoo! My Web | Furl

Bookmark WebProNews:

Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage (www.thebryantadvantage.com), home of FREE CCNA and CCNP tutorials and daily exam questions, as well as The Ultimate CCNA and CCNP Study Packages.

For a FREE copy of his latest e-books, “How To Pass The CCNA” or “How To Pass The CCNP”, and for free daily exam question, visit the website and download your copies!

It’s definitely not easy for the typical computer user, so when you get the call (we’re assuming that you are the professional who gets called with problems), what you are told may not match reality. This isn’t to imply that users are stupid, or ignorant, or careless (though some are all of those things), but simply that they may misinterpret symptoms and miss seeing the real problem.

Professionals do the same thing. In my career I’ve had more than one telephone call where someone describes themselves as a competent Windows administrator but apologizes for not “knowing Unix”. Sometimes we end up having an easy conversation where the problem really is simply that they need a little (sometimes a very little) Unix guidance to help them fix their issue. Sometimes it’s a little more involved: they’ve hit a tough nut and they’d really have needed years of experience to have any hope of fixing things.

Sometimes it’s not like that at all. More than once the immediate problem was a dead, non-booting machine. I don’t mean that Linux or Unix was trying to load and failing along the way, I mean that you could push the power button and the lights would come on and that was it. Nothing more. No BIOS display, no disk spin up, no beeps, nothing. Just dead. And yet here we have a supposedly competent Windows support person asking me what to do. What’s that have to do with me? It’s not a Unix issue – we haven’t got that far yet. It might become a Unix issue: if the hard drive has been damaged by whatever caused the stubborn nothingness being seen now, we might need a data recovery firm with knowledge of Unix/Linux file systems. Even if it’s just a missing boot sector, repairing that certainly requires OS specific knowledge. But right now? This is a low level hardware issue. Maybe a failed motherboard, power supply or missing/unplugged cables. Whatever is going on, right now it has nothing to do with Linux or Unix.

If you are dealing with a non-computer savvy user, remember that they may not understand things that seem obvious to you. For example, the user may understand that the hard drive stores his operating system and files, but may not realize that the initial BIOS information that flashes by at boot doesn’t come from there. So while you would think very differently about a machine that displays BIOS information but does not continue versus a machine that displays no BIOS data at all, the user of that machine might not. You need to interpret problem reports with an eye toward the reporters knowledge.

But you know that. You also know that if it is your suspicion that somebody did something they shouldn’t have, the user may not be willing to admit to it. You are going to take everything with a big helping of salt, and decide for yourself what the problem is. After all, you are the professional.

OK. But professionals also misinterpret things. You probably know this too: what you think you know can hurt you more than what you don’t know. Do I assume too much? Maybe so: I know I make mistakes like that, and I’ve sure seen other people do the same thing, but you could be different. If so, you can either skip the rest of this post or read it with relish while you savor your superiority.

I can remember the first bad troubleshooting mistake I made. It cost me a good customer – not because they were angry with me, but because I had them switch to hardware and software I did not support. I advised them to switch because I thought the OS and hardware they were running on had reached its performance limits. They were running a product called Glovia on a SCO Unix 80386 box. There were only about twenty users, but the background code had been getting more and more complicated over the years, and the system was slowing down badly. I tried increasing swap, adding more memory, and everything else that I could think of, but it kept getting worse. As their Glovia programmer was constantly adding new features, I assumed that these new routines were simply overtaxing the system: heck, I could see it in the sar reports: both the cpu and disk i/o were under excessive load. Basically, I just gave up and agreed with the advice they had received from Glovia and their programmer: upgrade to a big HP/UX system. They did, performance returned to acceptable levels, but because I didn’t know much about HP/UX, another consultant took over my position. I felt good about it overall: I had done the right thing, and I had more clients than I needed anyway. All parties pleased, time to move on.

But I was very, very wrong. I assumed the increasing load was from the heavy new tasks being added weekly, so I just didn’t look far enough. I had done some “ps” runs, but had missed seeing something very important. The clutter of Glovia processes blinded me: I didn’t see the big lumbering elephant in the crowd of dancing lambs. What I missed was an MMDF process called “deliver”. The reason I probably missed it was because I was looking for processes that were gaining time right now: I’d take two “ps” snapshots and “diff” them (this procedure is covered in more detail in a later chapter). The processes that popped out had used cpu time between the snapshots. If I had been lucky, “deliver” would have been in that list, but my timing was unfortunate: although “deliver” was using a lot of cpu, it didn’t happen to be sucking any at the times I happened to look.

I know this because I accidentally saved some printouts from that system. For some reason I had tucked them in my briefcase and forgot all about them. When I found them a few years later while searching for something else, I happened to take a quick glance, recognized where they were from, and immediately had an awful feeling in the pit of my stomach. I got that feeling because I noticed “deliver” and saw that it had a lot of accumulated time. In the intervening years, I had seen that at other SCO Unix jobs, and I knew what it meant. It meant that there were thousands, perhaps tens of thousands, of mail messages backed up on the system. That “deliver” process was trying desperately to run through them to see if they could now be delivered. It would do a lot of disk i/o and consume a lot of cpu in the process, and then it would go away until it was scheduled to run again. Eventually there were so many messages that it was almost always running – except when I ran my snapshots, of course. Just my luck, I guess – or more likely I just didn’t run enough of them because I saw all those Glovia processes and “knew” they had to be the problem.

Why didn’t the customer notice backed up email? Because it was root’s messages that were being delayed (due to a lock file on root’s mail folder) and nobody cared about root’s mail. User’s mail of course was getting slower and slower, but I took that as symptomatic rather than closer to causal. My loss: I saw what I expected to see, I didn’t see anything else, and I gave away a good account years before I had to.

*Originally published at APLawrence.com

Bookmark WebProNews:

A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com

And of course, it\s not enough to notice these details – you\ve got to know what to do about them!

A Cisco router is a DTE by default, but directly connecting two DTEs with a DCE/DTE cable is not enough. In the following example, R1 and R3 are directly connected at their Serial1 interfaces. The line goes up briefly after being opened, but the line protocol goes down after about 30 seconds.

R3(config-if)#int s1

2d18h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to down

The problem is that one of the routers needs to act as the DCE in order for the line protocol to come up and stay up. If this were your CCNA / CCNP home lab, you could just go over and look at the DTE/DCE cable to see which router had the DCE end of the cable attached. In this example, though, we don\t have physical access to the routers. How can we tell which router has the DCE end of the cable attached?

R3#show controller serial 1

buffer size 1524 HD unit 1, V.35 DCE cable

The show controller command gives us this information. (There\s a lot more output that this with this command, but it\s unimportant for our purposes.) The router with the DCE end of the cable needs to supply a clock rate to the DTE, and we\ll do just that with the interface-level clockrate command.

R3#conf t

2d18h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up

In just a few seconds, the line protocol goes up and stays up.

When troubleshooting a connection, always run show interface first. If you see the combination shown below, the connection is physically fine but logically down. That\s generally the result of a needed keepalive not being present. With Frame Relay, it\s probably an LMI issue, but with directly connected serial interfaces the issue is most likely the DCE end of the connection not supplying clockrate.

R3#show interface serial 1

Serial1 is up, line protocol is down

Troubleshooting is a big part of the job, and it\s a big part of the Cisco CCNA and CCNP programs as well. Know your show and debug commands and you\re on your way to passing the CCNA!

Add to Del.icio.us | DiggThis | Yahoo! My Web | Furl

Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage (www.thebryantadvantage.com), home of FREE CCNA and CCNP tutorials and daily exam questions, as well as The Ultimate CCNA and CCNP Study Packages.

For a FREE copy of his latest e-books, “How To Pass The CCNA” or “How To Pass The CCNP”, and for free daily exam question, visit the website and download your copies!

Whether you’re planning on passing the CCNA exam or just brushing up on your networking skills, this VTP tutorial will help you learn the basics of this important protocol.

VTP allows switches to advertise VLAN information between other members of the same VTP domain. VTP allows a consistent view of the switched network across all switches. When a VLAN is created on one switch in a VTP server, all other VTP devices in the domain are notified of that VLAN’s existence. VTP servers will know about every VLAN, even VLANs that have no members on that switch.

Switches run VTP in one of three modes. In server mode, VLANs can be created, modified, and deleted on a VTP server. When these actions are taken, the changes are advertised to all switches in the VTP domain. VTP Servers keep VLAN configuration information upon reboot.

In client mode, the switch cannot modify, create, or delete VLANs. VTP clients cannot retain VLAN configuration information upon reboot; they have to obtain this information from a VTP server.

In real-world networks, this is generally done to centralize the creation and deletion of VLANs. An interesting side effect of the server/client methodology is that if a VLAN is only to have ports on the VTP client switch, the VLAN must still first be created on the VTP server. The VTP client will learn about the VLAN from the VTP server, and ports can then be placed into that VLAN.

The third VTP mode is transparent mode. VTP switches in this mode ignore VTP messages. They do forward the VTP advertisements received from other switches. VLANs can be created, deleted, and modified on a transparent server, but those changes are not advertised to the other switches in the VTP domain.

For switches running VTP to successfully exchange VLAN information, three things have to happen. I’ve listed them for you in the order that you’ll see them in the real world.

The VTP domain name must match. This is case-sensitive. “CISCO” and “cisco” are two different domains.

To distribute information about a newly-created VLAN, the switch upon which that VLAN is created must be in Server mode.

Learning VTP isn’t just a good idea for passing your CCNA exams, it’s a skill you must have to be effective in configuring and troubleshooting VLANs. I wish you the best in both of these pursuits!

Add to Del.icio.us | DiggThis | Yahoo! My Web | Furl

Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage (www.thebryantadvantage.com), home of FREE CCNA and CCNP tutorials and daily exam questions, as well as The Ultimate CCNA and CCNP Study Packages.

For a FREE copy of his latest e-books, “How To Pass The CCNA” or “How To Pass The CCNP”, and for free daily exam question, visit the website and download your copies!

Im not even talking about the routing loops and suboptimal routing that can result when route redistribution is done without proper planning – Im talking about the basic commands themselves. Leaving out one single command option, or forgetting what else needs to be redistributed when redistributing dynamically discovered routes, can leave you with a routing table that looks complete but does not result in full IP connectivity.

In this free CCNP / BSCI tutorial series, well take a look at three common errors in route redistribution configurations, and how to fix them. Well use three routers, R1, R3, and R5. R1 and R5 are in a RIPv2 domain and R1 and R3 are in an OSPF domain. R1 will be performing two-way route redistribution.

R5 is advertising its loopback, 5.5.5.5/24, into the RIPv2 domain. R1 sees this route in its RIP routing table:

R1#show ip route rip

    5.0.0.0/24 is subnetted, 1 subnets

R    5.5.5.0 [120/1] via 100.1.1.5, 00:00:01, Ethernet0

For R3 to see this route, route redistribution must be configured on R1. Well use the redistribute rip command to do so.

R1(config)#router ospf 1

R1(config-router)#redistribute rip

% Only classful networks will be redistributed

The router immediately gives us a message that “only classful networks will be redistributed”. What does this mean? Lets go to R3 and see if that router is receiving this route.

R3#show ip route ospf

    < no output >

When we get no result from a show command, that means theres nothing to show. The only routes that will be successfully redistributed with the current configuration on R1 are classful networks, and 5.5.5.0/24 is a subnet.

To further illustrate the point, a classful network has been added to R5. This network is 16.0.0.0 /8, and is now being advertised by RIP. R1 sees this network as classful…

R1#show ip route rip

R    16.0.0.0/8 [120/1] via 100.1.1.5, 00:00:00, Ethernet0

    5.0.0.0/24 is subnetted, 1 subnets

R    5.5.5.0 [120/1] via 100.1.1.5, 00:00:00, Ethernet0

… and R3 is receiving the route through redistribution.

R3#show ip route ospf

O E2 16.0.0.0/8 [110/20] via 172.12.123.1, 00:00:08, Serial0.31

To redistribute both classful and classless networks, the option “subnets” must be added to the redistribute command on R1.

R1(config)#router ospf 1

R1(config-router)#no redistribute rip

R1(config-router)#redistribute rip subnets

R3 will now see both the classful and classless networks being redistributed into OSPF. (100.1.1.0 is the network connecting R1 and R5.)

R3#show ip route ospf

O E2 16.0.0.0/8 [110/20] via 172.12.123.1, 00:00:20, Serial0.31

    100.0.0.0/24 is subnetted, 1 subnets

O E2     100.1.1.0 [110/20] via 172.12.123.1, 00:00:20, Serial0.31

    5.0.0.0/24 is subnetted, 1 subnets

O E2 5.5.5.0 [110/20] via 172.12.123.1, 00:00:20, Serial0.31

This is one of the most common errors made during route redistribution, but now you know what to look out for! In the next part of this free CCNP / BSCI tutorial, well take a look at another such error.

Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage (www.thebryantadvantage.com), home of FREE CCNA and CCNP tutorials and daily exam questions, as well as The Ultimate CCNA and CCNP Study Packages.

For a FREE copy of his latest e-books, “How To Pass The CCNA” or “How To Pass The CCNP”, and for free daily exam question, visit the website and download your copies!

People just getting started with AdSense now have some extra help in negotiating some of the more troublesome issues encountered. Google has placed a Macromedia Breeze application online to assist.

The presentation walks users through a series of instructive slides discussing the hows and whys of getting AdSense code and placing it on a web page. A narrator discusses the salient points of each slide, providing assistance on understanding them.

This help focuses on the new AdSense user, likely a person who’s just started a new blog and wants to incorporate some ads into the site. A high level of HTML understanding is not required. Four common problems new users encounter have slides discussing their resolutions.

David Utter is a staff writer for WebProNews covering technology and business. Email him here.