I apologize. Apparently, my jedi skills come at the expense of my communication skills. We did not get 802.3ad working on the DGS-1248T. That would have been mode 2 (balance-xor and layer3+4 hashing). However, 802.3ad worked fine on the DGS-1210-48. Honestly, I didn't notice much difference between the two, although my understanding was that 802.3ad would allow one to bond ports on different switches (which we never tried).

Your experiences with round-robin scheduling is interesting. I seem to remember having to fiddle with some network stack settings on the Linux servers to get speed-up. It made the TCP stack more forgiving of out-of-order packets. Without that change, performance was horrible. So we could get increased performance between Linux servers, but at the expense of Windows workstations, which was unacceptable to us. In any case, if I'm ever in a position to use bonding under Linux again, I'll give round-robin sheduling a try again.

Our use case with imaging was sending out an image from a server to many workstations, from twenty to forty. The software allowed imaging of ten workstations at once, so a lot of the disk reads got cached. On some very old models of workstation, slow disks were an issue, but normally even twenty slow disks were fast enough not to be the bottle-neck. Imaging ten workstations was a bit slower than imaging one, but not much. During normal work-days, we would dial back the number of machines being imaged at a time to five or less, otherwise the staff would notice the network bogging down and lynch us.

To benchmark, we used...iperf! We would start an iperf server on the server machine, then run around all of the workstations and type the command for the iperf client onto the command-line without hitting enter. Then we would zip down the line of workstations hitting enter as fast as possible. That was with Windows workstations. With Linux workstations we used at to run the iperf client with the appropriate parameters all at the same time.

Checked your blog article. That brought me back a long way. My first install of Linux was Slackware in 1995. Jumped to Debian about 18 months later and never looked back. I feel your pain regarding trunking versus bonding. Once I realized that switch manufacturers called bonding trunking and that Linux driver writers called trunking bonding, it was only a few hours before I was testing my first bonded interfaces.

I'm pretty sure we were using revision b of the DGS-1248T. But it didn't support 802.3ad. (Apologies again for my miscommunication.)

We also had problems when accessing the DGS-1248T's web interface from Linux machines. Accessing the pages for controlling VLANs would put the switch in an unusable state. The only fix was to set the switch to factory defaults. That problem made for some late nights.

Apparently, later revisions of the firmware fixed the problem.

No worries about the miscommunitcation--I'm just glad you clarified! Just good to know that I wasn't chasing smoke after all

You know, I experienced the very same issue you mentioned w/ accessing the switch UI from w/in vlan'd systems. I couldn't access the UI at all. If by reverting to defaults, you mean reverting the port back from the modified VLAN into VLAN1, then yes, that was all I could do.

Apparently, I'm using the latest revision of the firmware that is available for hardware A. I can't complain though.. I did get the DGS-1248T for 10 bucks

Because I saw trunking/Bonding in the title, I was very curious if you guys ever got it working? The highest speeds I reached with my dual gig lan across all 802.3 setups gave me 950Mbps, but nothing more, sometimes I can burst up to 135MBps, but never more than a second.
One PFSense Bond, one Ubuntu Bond, and one Windows Intel device bond, all three never get higher than 950Mbps, and have never used both nics. However I am not sure all my settings are correct, and even when I added in my supporting 802.3ad switch, and tested all again, with proper settings in the switch, it still would hash to a single port.

At the moment I am happy because I can run everything through one port while my wife uses another to watch shows, but I would like to get dual nics working for a full 2Gbps.

Depending on your definition of "working", I definitely had success. The redundancy aspect is nice. If one link goes down, everything keeps running. Also, I did see multiple links chugging away, but only when more than one pair of clients was involved. We routinely had 30 or 40 workstations being imaged by a single server, and multiple links were clearly involved, but only yielded 1.6X throughput increase over a single link. (Actually, the performance increase may have been as small as 1.3X. It's been a while.) My understanding was that better switches are capable of very nearly saturating multiple links using 802.3ad, but again, only when multiple clients were involved.

When we standardized on pfSense at our facilities, we realized that the D-Link 1248T and DGS-1210 were not up to the task of fully using LAGG/bonding/trunking. That's when we began looking at better switches. Alas, I moved on before being able to put that problem to rest.