package manager failed with update from snv_129 to snv_130

I had my pkg publishers as followed:
dev                   http://pkg.opensolaris.org/dev/   
opensolaris.org  http://pkg.opensolaris.org/release/

But this just results in pkg refresh failing:
-To correct the repository origin, execute the following command as a privileged user:

pkg set-publisher -O opensolaris-dev

To add a new publisher using this publisher's repository origin, execute the following command as a privileged user:

pkg set-publisher -O http://pkg.opensolaris.org/dev/

After the new publisher has been added, this one should be removed by executing the following command as a privileged user:

pkg unset-publisher opensolaris-dev

I tried to follow the suggestions but to no avail.
Then I read it was mentioned to have only 1 publisher opensolaris.org as Preferred and delete dev resulting in the following pkg publisher:
opensolaris.org   http://pkg.opensolaris.org/dev/ 

But still the package manager failed to upgrade to 130 as did pkg refresh
In the forum (http://www.pubbs.net/opensolaris/200912/32545/) it was mentioned to use "pkg image-update -f"  due to errors related to release snv-128 and 129 (Option -f bypasses SUNWipkg)

Update succeeded to 130.

3com 3C200-T Gigabit network card (tcge)

I was not happy with the throughput using the onboard NIC so I installed the 3com Gigabit NIC which supports jumbo frames. NIC is not recognized by OS as standard so you have to get the driver from Asustek:
http://dlsvr01.asus.com/pub/ASUS/lan/3com/3c940/046_Solaris.zip

Just follow the instructions provided and your NIC will be recognized and fully functional.

iscsi performance

Besides the settings mentioned in the iSCSI uguide from Microsoft: Setting TcpAckFrequency =1

Someone mentioned lack of performance was solved by disabling the "receive Windows auto tuning". See: http://support.microsoft.com/kb/947239

Server refused to allocate pty snv_128 and 129

after upgrade to snv_129 I was not able to login using ssh.

this is a known bug which can be solved by editing /etc/minor_perm
add the following:
"clone:ptmx 0666 root sys" to /etc/minor_perm

After reboot you can login again with ssh
(source: http://defect.opensolaris.org/bz/show_bug.cgi?id=12380)

Nagle Algorithm

Please take a look at the node where the iSCSI Initiator is running and determine if the following parameter is being set.

[ /kernel/drv/iscsi.conf ] add the following:

#

# Disable Nagle within the iSCSI Initiator

#

tcp-nodelay=1;

The tcp-nodelay setting, alters the iSCSI Initiators socket options by setting the well-known option TCP_NODELAY, or more specifically turning off the "Nagle Algorithm". For performance reasons, this setting is hard-coded in the iSCSI Target and also Availability Suite's SNDR, both being TCP/IP based data movers of disk blocks.

For both iSCSI and SNDR, the Nagle algorithm interacts badly when using TCP delayed acknowledgments, of which both iSCSI and SNDR relies upon. These performance issues have been noted by many others, including the author John Nagle. See link at bottom of this page: http://en.wikipedia.org/wiki/Nagle's_algorithm

For Windows check the Microsoft ISCSI User Guide to change TCPIP parameter
in registry: "TcpAckFrequency=1"
(http://download.microsoft.com/download/A/E/9/AE91DEA1-66D9-417C-ADE4-92D824B871AF/uGuide.doc)

iscsi performance

(Source: http://opensolaris.org/jive/thread.jspa?threadID=78965)
Sidenote: Today we made eight network/iSCSI related tweaks that, in aggregate, have resulted in dramatic performance improvements (some I just hadn't gotten around to yet, others suggested by Sun's Mertol Ozyoney)...

- disabling the Nagle algorithm on the head node

- setting each iSCSI target block size to match the ZFS record size of 128K

- disabling "thin provisioning" on the iSCSI targets

- enabling jumbo frames everywhere (each switch and NIC)
- raising ddi_msix_alloc_limit to 8
- raising ip_soft_rings_cnt to 16
- raising tcp_deferred_acks_max to 16
- raising tcp_local_dacks_max to 16

Rerunning the same tests, we now see...

[1GB file size, 1KB record size]
Command: iozone -i o -i 1 -i 2 -r 1k -s 1g -f /data-das/perftest/1gbtest

Write: 143373
Rewrite: 183170
Read: 433205
Reread: 435503
Random Read: 90118
Random Write: 19488

[8GB file size, 512KB record size]

Command: iozone -i 0 -i 1 -i 2 -r 512k -s 8g -f /volumes/data-iscsi/perftest/8gbtest
Write:  463260
Rewrite:  449280
Read:  1092291
Reread:  881044
Random Read:  442565
Random Write:  565565

[64GB file size, 1MB record size]
Command: iozone -i o -i 1 -i 2 -r 1m -s 64g -f /data-das/perftest/64gbtest

Write: 357199
Rewrite: 342788
Read: 609553
Reread: 645618
Random Read: 218874
Random Write: 339624

Thanks so much to everyone for all their great contributions!
-Gray

Using POPtray to check your Axigen Mail

To check your Axigen mail using POPtray you need to tick the following
box in Axigen Console: Services: POP3
On UNSECURED connections allow authentication with:
Normal login (unsecured)
( Otherwise you get "Invalid Authentication Type" message  within POPtray when you check your account)