Adafruit 2097 (and other) TFT displays

There are a bunch of issues with the Adafruit 2097 TFT preconfigured image and getting it fully up and running with X.

This applies specifically to the patched raspian image for this product.  Others may or may not be patched correctly.  This appears to be a raspian from about 12/2014, FWIW

http://www.adafruit.com/products/2097

Notes for configuring it to run completely on the TFT:

See starting X on the TFT display below

Notes for configuring wifi (since the USB on the pi boards suck completely

This should be done with an exported X environment, or with the HDMI display attached.  These are fixed mode dialogs and don't scale or scroll like they should.

run the wifi gui.  select scan on the main gui.
on the next dialog, select scan, and when the desired device shows up, double click it, and add it to the configuration.  This should bring up a large dialog, and if the thing is configured right, one can enter the wifi password in that dialog.


Notes for starting X on the TFT display

The problem is that the tutorial expects you to use startx, rather than letting lightdm start the X server (as it does when you select boot to desktop). When you select boot to desktop the greeter is started to allow you to log in. The solution is to follow this tutorial (X11 on your Display). Boils down to:-

Install xserver-xorg-video-fbdev

CODE: 

sudo apt-get install xserver-xorg-video-fbdev

sudo apt-get install xserver-xorg-video-fbdev

Create a config file with following contents in /usr/share/X11/xorg.conf.d/99-fbdev.conf containing the following:

CODE: 

Section "Device"
  Identifier "myfb"
  Driver "fbdev"
  Option "fbdev" "/dev/fb1"
EndSection

Section "Device"  
  Identifier "myfb"
  Driver "fbdev"
  Option "fbdev" "/dev/fb1"
EndSection

Adafruit note page on point (not in tutorial)

https://learn.adafruit.com/adafruit-pitft-28-inch-resistive-touchscreen-display-raspberry-pi/extras#boot-to-x-windows-on-pitft

vmware esxi command line performance command, network tracing

Performance, or top command for esxi is esxtop


To capture network activity on esxi with command line,  one must use a different special form of the tcpdump command.

Take care to position where you will have some storage capacity.  Though logged in as root, the root fs structure may have very little storage in its default directory.  Also on systems with tcp nas, traffic will be added if one used datastores which are mounted via nfs or other protocols visible to the NIC.

notes captured from this info page

http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1031186

Capturing network traces with tcpdump-uw

• To list the vmkernel interfaces, use the esxcfg-vmknic command with the -l option:
  
  # esxcfg-vmknic -l
  
• To display packets on the vmkernel interface vmk0, use the tcpdump-uw command with the -i option:
  
  # tcpdump-uw -i vmk0
  Note:
  
  • By default, the tcpdump and tcpdump-uw commands capture only the first 68 bytes of data from a packet.
  • For ESXi 5.5, see Using the pktcap-uw tool in ESXi 5.5 (2051814).
    
    
• To capture the entire packet, use the tcpdump-uw command with the -s option with a value of 1514 for normal traffic and 9014 if Jumbo Frames are enabled.
  
  Normal traffic: # tcpdump-uw -i vmk0 -s 1514Jumbo Frames enabled: # tcpdump-uw -i vmk0 -s 9014 -B 9
  
  Note: By default, tcpdump-uw can only capture a maximum of 8138 bytes due to buffer constraints. The -B 9 option increases the buffer to allow the capture of up to 9014 bytes.
  
  
• To display all of the packets on vmk0 with verbose detail,  use the tcpdump-uw command with the -vvv option:
  
  # tcpdump-uw -i vmk0 -s 1514 -vvv
  Note: Refer the help page for tcpdump-uw command for more -v options.
  
  
• To display only the TCP packets on vmk0, use the tcp option with the tcpdump-uw command.
  
  # tcpdump-uw -i vmk0 -s 1514 tcp
  
• To see traffic to/from only a single IP address, you can use the host option:
  
  # tcpdump-uw -i vmk0 -s 1514 host x.x.x.x
  
  
• To avoid seeing unwanted traffic types in the tcpdump-uw output, use the not option. For example, to filter out DNS and SSH traffic, use the following command:
  
  # tcpdump-uw -i vmk0 -s 1514 port not 22 and port not 53
  
  Note: This is useful when doing a packet capture on a VMkernel interface when that same interface is also being used for an active SSH session.
  
  
• To save the dump in pcap format for later use with Wireshark, use the traffic.pcap option.
  
  # tcpdump-uw -i vmk0 -s 1514 -w traffic.pcap
  
• If the trace is running for long time, you can split the trace pcap file to chunks of desired size using the-C option.
  
  # tcpdump-uw -i vmk0 -s 1514 -C 100M -w /var/tmp/test.pcap
  
• To limit the log files to a specified number, you can use the -W option. You can use this option if a trace must be set running for a long period of time, waiting for an even to occur.
  
  For example:
  
  # tcpdump-uw -i vmk0 -s 1514 -C 100M -W 10 -w /var/tmp/test.pcap
  This command creates 10 trace files of size 100MB each. This ensures that you do not run out of space on ESX.
  
  Note: This option has the same effect of rotating the log files.

Traffic on a virtual internal switch must be captured in a different manner.

notes taken from here:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1000880

Capturing virtual switch traffic with tcpdump and other utilities (1000880)

Details

This article provides information about capturing ESX network traffic.

There are two ways to capture traffic in an ESX environment:

• On the Service Console level:
  
  ESX ships with the tcpdump utility. For more information on usage, see Troubleshooting network issues by capturing and sniffing network traffic via tcpdump (1004090).
  
  
• On the guest operating system (GOS) level:
  
  Depending on the operating system type, different utilities may be available to download for capturing network traffic.

Monitoring virtual switch traffic using tcpdump or other packet-capture utilities requires a port group with non-default security policies set.

Attempting to capture traffic without adjusting the security policies results in silent failure of the capture operation.

Solution

These steps describe setting up a vSwitch and/or a port group in promiscuous mode for tcpdump:

1. To monitor traffic via VMware Service Console (SC), a port group and a vswif interface with security settings modified to promiscuous mode accept is required for capturing.
2. To monitor traffic via the virtual machine, the virtual machine's virtual NIC must be set to promiscuous mode accept, however this step is often accomplished by the capturing utility installed on guest operating systems. The Virtual Switch (vSwitch) and port group security settings must also be modified to accept all traffic ( promiscuous mode accept).
3. To capture all traffic of the Virtual Switch, the vSwitch security setting is set to promiscuous mode accept.
4. To capture only the traffic of a port group, only that particular port group security setting is modified to promiscuous mode accept.
5. A layer 3 IP address is used by the capturing utility, therefore you must have a Service Console with an IP address in the desired subnet for capturing. This also applies to guest operating systems.
6. To monitor VMkernel Traffic, place a Service Console on the VMkernel virtual switch, and follow the procedure below.

These steps must be applied as a whole if the environment requires total dedicated virtual switch, port group, and service console, or can be used as reference to modify existing network settings. To modify only the port group, go to step 3 above.

Create a new service console portgroup named COS_tcpdump (or another name which makes sense in your environment):

1. Connect to the ESX host using VI Client / vSphere Client.
2. Click the ESX host, then click the Configuration tab.
3. Click Networking under Hardware.
4. Click Add Networking, which is located at the top right. The Add Network Wizard window appears.
5. Click Service console, then click Next.
6. Select Create a virtual switch and select the NIC to be associated with the virtual switch and click Next.
7. Enter a Network Label for the server console (in this example, COS_tcpdump), and provide a VLAN ID (optional).
8. On ESX 4.x, click Next.
9. Assign IP information using DHCP or manually by entering an IP Address and Subnet Mask, then click Next.
10. Click Finish to create the switch.
11. Click Properties next to the new virtual switch to edit its properties.
12. Highlight the newly created Service Console and click Edit to modify its properties.
13. In the vSwitch Properties window, click the Security tab and change all three Policy exceptions to Accept and click OK.
14. Close the Properties window. You are ready to run tcpdump on this vswif interface.

cubox setup notes

with the debian jesse of 3/9/2015, I had to set up the network manually.

copy the contents of /etc/network/intefaces.d/eth0 to the new image.

apt-get -y install cifs-utils  (still work in progress)

apt-get -y install nfs-common nfs-server to get nfs stuff set up

cifs mounts are not running, but smbd is running fine.  Still to gen up further testing as of 4/12/15

Film tables, 8mm, 16mm, and 35mm lengths, time and speed tables.

Time/Footage for Various Film Formats

Time	Reg. 8mm	Sup. 8mm	16mm	35mm
10 sec.	3 feet	3 1/3 feet	6 feet	15 feet
30 sec.	9 feet	10 feet	18 feet	45 feet
1 min.	18 feet	20 feet	36 feet	90 feet
3 min.	54 feet	60 feet	108 feet	270 feet
5 min.	90 feet	100 feet	180 feet	450 feet
10 min.	180 feet	200 feet	360 feet	900 feet
20 min.	360 feet	400 feet	720 feet	1800 feet
30 min.	540 feet	600 feet	1080 feet	2700 feet

Feet to minutes calculator for 16mm film:
minutes=feet*40/24/60 or minutes=feet*0.0278
1 foot of 16mm is 40 frames.
100' of 16mm is 2.78 minutes, or 2 minutes and 45 seconds
400' of 16mm is 11.11 minutes, or 11 minutes and 6 seconds
1 foot of 35mm is 16 frames.
100' of 35mm is 1,600 frames. 1,600 frames/24 fps = 66.6 seconds.

http://www.intervalometers.com/resource/index.php