I've done nothing overnight but now I get 3.7 megs on ipv6 on the same test page (consistently,
though of course it's now a different time of day)

I'm using:

ipv6 mtu 1452

on my router's tunnel0 (and on the HE config page).

(the ip mtu on my pppoa dialer interface is
ip mtu 1478 and I use  ip tcp adjust-mss 1438
)

using ping6 -s (value) www.youtube.com

it works up to  value = 1404

it's possible that my immediate problem has gone away for no particular reason

the beginning of "show ipv6 traffic" looks like this:

lounge#show ipv6 traffic
IPv6 statistics:
   Rcvd:  762495 total, 9918 local destination
          0 source-routed, 155 truncated
          139 format errors, 50 hop count exceeded
          0 bad header, 0 unknown option, 0 bad source
          0 unknown protocol, 0 not a router
          0 fragments, 0 total reassembled
          0 reassembly timeouts, 0 reassembly failures
   Sent:  11896 generated, 402539 forwarded
          0 fragmented into 0 fragments, 0 failed
          0 encapsulation failed, 0 no route, 486 too big
          1286 RPF drops, 0 RPF suppressed drops
   Mcast: 65 received, 849 sent

it seems plausible that the errors are mostly me trying to send overly big packets.

I am using IOS 15.1(4)M4 (advanced ip services) on a cisco 877.

I am happy enough with 3.7 megs of IPv6 but if there are errors in my config I'm all ears.

The CPU usage is more likely dependent on the number of packets per second rather than the number of bytes per second. It might be that the IPv6 traffic uses smaller packets than IPv4. In many installations the IPv4 packet size is limited by the Ethernet MTU of 1500 bytes. But for IPv6 it might have been decided to use only 1280 bytes per packet, because the IPv6 standard guarantees that packet size can be sent without fragmentation.

The difference between 1500 and 1280 bytes isn't all that much, but if you are CPU bound, it matters. Also tunnelling is very likely to require more CPU time than just forwarding an IPv4 or an IPv6 packet. In fact since the packet is likely going through the IPv4 routing code once and through the IPv6 routing code once, I would guess the total CPU usage is the sum of the two. Assuming the IPv4 and IPv6 routing code are roughly the same speed, you will get only half the speed for tunnelled packets.

In total those factors could explain a factor of 2.3 more bytes per second with IPv4 than with an IPv6 tunnel. How large a difference do you see?

I am currently downloading a freebsd .iso image using v6 and my 877 says:

01:12:15 PM Sunday Jul 15 2012 BST
                                                               
      999999999999999999999999999999999999999999999999999999999999
      999999888886666688888888887777799999999999999999999999999999
  100 ************************************************************
   90 ************************************************************
   80 ************************************************************
   70 ************************************************************
   60 ************************************************************
   50 ************************************************************
   40 ************************************************************
   30 ************************************************************
   20 ************************************************************
   10 ************************************************************
     0....5....1....1....2....2....3....3....4....4....5....5....6
               0    5    0    5    0    5    0    5    0    5    0
               CPU% per second (last 60 seconds)

looking at show proc cpu, standouts are:

255      904965      207927       4352 34.33% 34.67% 23.47%   0 IPv6 Input   
 105      536119      345553       1551 20.74% 19.92% 13.16%   0 IP Input 

I see that I have "ipv6 virtual-reassembly" enabled on vlan1 and tunnel0. It seems to be
doing nothing:

#show ipv6 virtual-reassembly
 All enabled IPv6 interfaces...
%Interface Tunnel0 [in]
   IPv6 configured concurrent reassemblies (max-reassemblies): 64
   IPv6 configured fragments per reassembly (max-fragments): 16
   IPv6 configured reassembly timeout (timeout): 3 seconds
   IPv6 configured drop fragments: OFF

   IPv6 current reassembly count:0
   IPv6 current fragment count:0
   IPv6 total reassembly count:0
   IPv6 total reassembly timeout count:0

%Interface Vlan1 [in]
   IPv6 configured concurrent reassemblies (max-reassemblies): 64
   IPv6 configured fragments per reassembly (max-fragments): 16
   IPv6 configured reassembly timeout (timeout): 3 seconds
   IPv6 configured drop fragments: OFF

   IPv6 current reassembly count:0
   IPv6 current fragment count:0
   IPv6 total reassembly count:0
   IPv6 total reassembly timeout count:0

yet if I remove it ipv6 seems to break.

looking at other postings I seem some people have it and some don't.

I am getting 5.6 megs of ipv6 traffic though:

show int tun0
Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Description: Hurricane Electric IPv6 Tunnel Broker
  MTU 17920 bytes, BW 1104 Kbit/sec, RxBW 15000 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 39/255, rxload 96/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel transport MTU 1458 bytes
  Tunnel transmit bandwidth 1104 (kbps)
  Tunnel receive bandwidth 15000 (kbps)
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters never
  Input queue: 34/75/2321/0 (size/max/drops/flushes); Total output drops: 0
  30 second input rate 5658000 bits/sec, 475 packets/sec
  30 second output rate 169000 bits/sec, 229 packets/sec

So this is better than my speed tests suggested I would get.

Back to 3.something megs on speedtest site again and youtube goes over 1 meg on ipv6. Whatever
this is, I don't see how it can be me.