Generically speaking, performance ought to be measured in a realistic situation, so you should use as client one of these sluggish set top boxes. When you connect to your server, run a network monitor tool on the server (e.g. Wireshark) to get the precise timings of exchanged packets; this will show what cipher suites the client supports (they are listed in the
ClientHello message), what the server decides to use (in the
ServerHello message), and pinpoint the operations where time is spent.
Performance issues with SSL will occur either during the handshake, or afterwards when actually sending and receiving data.
For the handshake, you may get issues with latency because a SSL handshake is four-way (two roundtrips before client begins to send the actual HTTP requests); however, this occurs only at the beginning of the SSL session. Browsers keep connections open.
At the handshake level, you may get some performance issue related to the asymmetric cryptography, although I don't quite believe it because a set top box which can run a modern Web browser ought to have enough punch to do such cryptography quite efficiently. You may want to make sure that your cipher suite uses a RSA key exchange (i.e. a cipher suite of type "RSA", not "DHE_RSA") because RSA key exchange is very light (computationally) on the client. However, in any case, since connections are kept open and SSL sessions reused, this may matter only for the very first connection from the client to a given server, and should not impact performance in a continuous way.
Another one-time impact is that for the very first handshake, the client must validate the server's certificate, and that can be expensive -- especially if the client must download some intermediate CA certificates, and obtain CRL and/or OCSP responses. You will not be able to change that with a choice of cipher suite. Make sure that your server sends a complete certificate chain to the client.
For continuous sluggishness, the symmetric encryption part would be a more plausible culprit. Roughly said, you want cipher suites which use AES or RC4, not cipher suites which use 3DES. 3DES is known to be slow.