I am always looking for a better flash drive and my current favorite is the Mushkin Atom. The Atom is not the smallest physical size drive, but it is faster than most of the competition. I use my flash drive with PortableApps, which allows me to have most of my apps on a flash drive. This is a great way to keep all your apps when switching between two Windows computers. The only downside I have found is that Google Chrome does not work as well. It is a bit slower for some reason. Firefox is my preferred browser and the PortableApps version works very well. As to the Mushkin Atom performance, I ran a quick test with USBDeview for Windows and read results were a third faster than my previous Sandisk drive.
This test was run on the Mushkin Atom 32GB USB3 flash drive with USBDeview 64. Your results may vary depending on your computer and USB port.
I have been using the Atom for about 3 months without any issues on a Windows 7 laptop.
Apple has a long history with computer networking, from AppleTalk to today’s Internet connected world. However, it is Windows networking that still causes all kinds of headaches for Mac OS X users. It seems that with every release of Mac OS X, Apple seems to have recurring issues with Windows shares. Some of Apple’s defenders will state that Apple adopts industry standards as is, and it is Microsoft and others who publish specs, but don’t actually follow them, so when Apple does follow the specs, it seems to just end up breaking things. SMB is the networking protocol that Microsoft uses for Windows networking. It is what allows Windows network file shares to work across the network. With the latest versions of Mac OS X, Apple abandoned the open source SAMBA package that most Linux distros use to connect to Windows, and wrote their own SMB2 software. This makes Mac OS X 10.9 Mavericks connect faster and better to Windows servers. Well that is when it works!
SMB Connections Fail
There is one Windows 2012 Essentials server with multiple shares. There are two Macs on the local network. One iMac is connected over Wireless N and one MacBook Pro is using a wired ethernet 1Gb connection. When using the Connect to Server… option the iMac connects fine and has no issues. The MacBook Pro opens the share and then never displays any files, it just spins in the lower left hand corner of the window that opens. Both computers are running Mac OS X 10.9.3 Mavericks.
Connecting via CIFS instead of SMB seems to work for the MacBook, but it is slower.
The solution ended up modifying the Windows 2012 Essentials server. There are two registry keys that need to be added in order to fix the problem for the MacBook.
Under this Registry Key:
Add these DWORD values:
- Smb2CreditsMin – make this 768
- Smb2CreditsMax – make this 16384
Once you made the changes restart the Windows Server and then the Macintosh clients. It should now fix the problem.
Microsoft provides the following information on these registry keys:
The defaults are 512 and 8192, respectively. These parameters allow the server to throttle client operation concurrency dynamically within the specified boundaries. Some clients might achieve increased throughput with higher concurrency limits, for example, copying files over high-bandwidth, high-latency links.
SARG Reports are a good compliment to Squid Proxy and since there is a package that is available for installation in pfsense, it makes good sense to setup SARG Reports. The downsides to SARG Reports is that the reports do take up space and over time this can be significant. This posting is about a problem I encountered on pfsense 2.1 and the latest SARG package.
For some unknown reason the reports stopped generating. Upon checking my System Log this is the issue I found:
php: /pkg_edit.php: The command 'export LC_ALL=C && /usr/pbi/sarg-amd64/bin/sarg -d `date +%d/%m/%Y`-`date +%d/%m/%Y`' returned exit code '1',
the output was 'SARG: Cannot get the modification time of input log file /var/log/squid/access.log (No such file or directory). Processing it anyway SARG: File not found: /var/log/squid/access.log'
I am using the 64-bit version of pfsense, so hence the sarg-amd64. If you are using 32-bit, it will state instead sarg-i386.
The solution is to edit the sarg.conf file that is located in one of these locations, depending on your pfsense build:
You will need to verify that the access_log line is correct:
In my case, removing the # sign and specifying the correct path to my Squid access.log corrected the problem.
If you have issues with SARG Reports, it is best to do the following:
- Under the Status Menu – click SARG Reports.
- On the General tab click Save
- Next click on the Users tab and click Save
- Click Schedule and create your schedule or if you have one already open it up and click Save.
- You can go back to the Schedule and Force Update to see if SARG Reports are working now.
I also schedule SARG Reports in Cron to run at 11:50pm every night instead of midnight.
50 23 */1 * *